System and Method for Identity Management

ABSTRACT

A computer-implemented method includes: receiving a request for associating a first index of privileges and permissions with an identity token, the first index specifically encoding the privileges and permissions of a first subscriber in accessing transactional data of the requester, the request including the identity token that identifies a person and has been issued to the requester by a trusted entity through a vetting process; in response to determining that the identity token is valid and verifying that the requester is the person identified by the identity token, associating the first index of privileges and permissions of the first subscriber with the identity token; and providing the identity token associated with the first index of privileges and permissions of the first subscriber, the identity token enabling the first subscriber to access transactional data of the requester in accordance with the first index of privileges and permissions.

TECHNICAL FIELD

This document generally relates to identity management.

BACKGROUND

Transactions between a consumer and a provider may be subject to risksof identity theft, identity fraud, spoofing, phishing, etc., all ofwhich may potentially hinder the flow of commerce.

SUMMARY

In one aspect, some implementations provide a computer-implementedmethod 1. A machine-assisted method for determining a trustworthiness ofa requested transaction, the method including: receiving, from aparticipant entity, a request to determine a trustworthiness of atransaction request, the transaction request being submitted by a userto access data managed by the participant entity; submitting a firstinquiry at an authentication verification engine to determine anauthenticity of a purported identity of the user submitting thetransaction request; receiving a response from the authenticationverification engine, the response including a computed authenticityscore quantitatively attesting to the purported identity of the usersubmitting the transaction request; based on the computed authenticityscore, determining the trustworthiness of the transaction request beingsubmitted by the user; and notifying the participant entity of thedetermined trustworthiness of the transaction request to access datamanaged by the participant entity.

Implementations may include one or more of the following features. Themethod may include further submitting a second inquiry at anauthentication policy server to determine a scope of right possessed bythe participant entity to verify identities of users through thetransaction authentication engine; receiving a reply from theauthentication policy engine, the reply including a computed validityscore indicative of the scope of the right of participant entity toverify identities of users through the transaction authenticationengine; based on the computed authenticity score as well as the computedvalidity score, determining the trustworthiness of the transactionrequest submitted by the user; and notifying the participant entity ofthe determined trustworthiness of the transaction request attempting toaccess data managed by the participant entity.

Additionally, submitting the second inquiry at the authentication policyserver may include submitting the second inquiry to determine a scope ofright of the participant entity to use a particular identity database;and wherein receiving the reply from the authentication policy enginecomprises receive a reply including a computed score indicative of thescope of right of the participant entity to use the particular identitydatabase.

Moreover, receiving a query result obtained from the particular identitydatabase in accordance with the scope of the right for the participantentity to access the particular database, wherein the query result is aresponse by the identity database to a submitted query at the identitydatabase.

Furthermore, determining the trustworthiness of the transaction requestcomprises determining the trustworthiness based on the query results aswell as the computed authorization score and the computed validityscore.

Still, the method may further include storing the received query resultand the corresponding query at the transaction authentication engine fortemporary storage; and allowing future queries at the particulardatabase to access the temporarily stored query result according to thedetermined scope of right for the participant entity to access theparticular database.

The method may further include obtaining an authentication policy fromthe authentication policy server, the authentication policy governingcommunication between the transaction authentication engine and theauthentication verification engine. The method may additionally include:configuring a protocol for communication with the authenticationverification engine. Moreover, configuring the protocol may furtherinclude: configuring the protocol according to the authentication policyas purchased by the participant entity. Furthermore, configuring theprotocol for communication may additionally include configuring a firstprotocol component for encrypting data being transmitted from thetransaction authentication engine to the authentication verificationengine; and configuring a second protocol component for decrypting databeing received by the transaction authentication engine from theauthentication verification engine.

In another aspect, some implementations provide a computer system Amachine-assisted method, the method including: receiving, at anauthentication verification engine and from an transactionauthentication engine, an inquiry regarding a user submitting atransaction request to access data managed by the participant entity,the inquiry comprising information identifying the user; based on theinformation identifying the user, constructing a query to verify anidentity of the user who has requested the transaction; submitting thequery to an identity database in communication with the authenticationverification engine; receiving a reply from the identity database inresponse to the query; based on the received reply, computing anauthenticity score quantitatively attesting to the identity of the userwho has requested the transaction; and providing the computedauthenticity score as a component to determine a trustworthiness of thetransaction request.

Implementations may include the following additional features. Themethod may further include gathering the information identifying theuser by: calling a method individually encapsulated in the transactionrequest; receiving a return value as a result of calling the method; andretrieving the information identifying the user in the received returnvalue. Additionally, gathering the information identifying the usercomprises: gathering information encoding a biometric of the user.Gathering the information identifying the user may include gatheringpersonally identifiable information of the user. Gathering theinformation may include: gathering information encoding a pair ofuser-name and password to access an on-line account. Gatheringinformation may include gathering data obtained from an identificationdocument of the user.

The method may further include configuring a protocol for communicationwith the identity database, the protocol being determined by aauthentication policy governing data access rights by the participantentity at the identity database. Configuring the protocol may furtherinclude configuring the protocol for communication according to theauthentication policy as purchased by the participant entity.Configuring the protocol for communication may further includeconfiguring a first protocol component for encrypting data beingtransmitted from the authentication verification engine to the identitydatabase; and configuring a second protocol component for decryptingdata being received by the authentication verification engine from theidentity database.

The method may further include maintaining parameters of the identitydatabase by configuring component fields of identity data of usersadmitted into the identity database through a vetting process. Themethod may additionally include managing, based on the protocol,attributes corresponding to the component fields of the identity data;and configuring, in accordance to the protocol, access to the componentfields of the identity data stored at the identity database. Configuringthe protocol for communication with the identity database may furtherinclude configuring the protocol for communication with an identitydatabase provided by a government entity, wherein the government entityadministers a vetting process to perform background check of the userbefore the corresponding identity data of the user is entered into theidentity database. Configuring the protocol for communication with theidentity database may additionally include: configuring the protocol forcommunication with an identity database provided by a third partyentity, different from a government entity and the participant entity.

In yet another aspect, some implementations may provide amachine-assisted method for controlling access to an identity databaseby a participant entity, the method including: receiving, from atransaction authentication engine, an inquiry regarding a participantentity attempting to verify an identity of a user submitting atransaction request at the participant entity; determining anauthentication policy for the participant entity to verify the identityof the user; based on the determined authentication policy, computing avalidity score for the participant entity to verify the identity of theuser; and providing the computed validity score to the transactionauthentication engine for determining a trustworthiness of thetransaction request submitted by the user at the participant entity.

Implementations may include the following features. The method mayadditionally include: based on the received inquiry, gatheringinformation identifying the participant entity; based on the gatheredinformation identifying the participant entity, determining theauthentication policy. The method may further include: based on thereceive inquiry, logging verification activities requested by theparticipant entity; and analyzing the logged verification activities todetermine a usage by the participant entity. The method may furtherinclude logging queries to access an identity database as part of theverification activities requested by the participant entity; andanalyzing the logged queries to determine the usage of the identitydatabase by the participant entity.

The method may additionally include profiling the logged queries todetermine a pattern of usage of the identity database by the participantentity. The method may further include based on the determined usage,performing accounting to determine a use fee to be charged to theparticipant entity for accessing the identity database. Performingaccounting may further include measuring at least one of: a number ofqueries by the participating entity to the identity database; an amountof data sent by the participant entity to access the identity database;a number of responses sent to the participant entity in response tocorresponding queries; or an amount of data sent to the participantentity in response to corresponding queries. Computing the validityscore may include comparing the determined usage by the participantentity with the authentication policy of the participant entity.

The method may additionally include providing an administrativeinterface to report the determined usage to a human administrator. Themethod may further include based on the determined usage, providingfeedback information to enable load balancing when submitting futurequeries to the identity database. The method may additionally includeproviding an application program interface through which theauthentication policy engine extends service for the participant entityto access other identity databases different from the identity database.The method may further include providing the application programinterface further comprises: providing the application program interfaceto allow a different authentication policy engine to access the identitydatabase serviced by the authentication policy engine.

In still another aspect, some implementations provide a machine-assistedmethod for integrated identity management, the method including:receiving, at a verified identity engine, a request to verify anauthorization status in association with a transaction request, thetransaction request being submitted by a user attempting to access datamanaged by a participant entity, the authorization status indicative ofa power of the participant entity to verify an identity of the user;determining the identity of the user submitting the transaction request;determining an identity of the participant entity; querying a databaseat the verified identity engine based on the determined identity of theuser and the determined identity of the entity submitting the request toverify; and according to query results, determining the authorizationstatus.

The method may further include in response to determining that thetransaction request is originally submitted by the user to theparticipant entity and that participant entity is not yet an authorizedbusiness partner of the user, registering, in the database at theverified identity engine, the participating entity as an authorizedbusiness partner of the user.

The method may further include: in response to determining that thetransaction request being submitted by the user was solicited by theparticipant entity, querying the database at the verified identityengine to determine whether the participant entity is an authorizedbusiness partner of the user.

The method may additionally include in response to determining that theparticipant entity is not yet an authorized business partner of theuser, alerting the user that the participant entity is not an authorizedbusiness partner. The method may further include in response todetermining that the participant entity is not yet an authorizedbusiness partner of the user, alerting the user that the participantentity is not an authorized business partner; and alerting the entitysubmitting the request to verify to hold off processing a particularrequest from the participant entity with regard to the user.

Querying the database at the verified identity engine may furtherinclude querying the database at the verified identity engine todetermine whether the participant entity, as an authorized businesspartner of the user, is authorized to engage in the requestedtransaction between the user and the participant entity.

Moreover, the method may additionally include in response to determiningthat the participant entity, as an authorized business partner of theuser, is authorized to engage in the requested transaction between theuser and the participant entity, signaling the participant entity toproceed with the requested transaction. The method may further includein response to determining that the participant entity, as an authorizedbusiness partner of the user, is not authorized to engage in therequested transaction between the user and the participant entity,alerting the user and the participant entity that the participant entityis not authorized to engage in the requested transaction.

The method may further include providing a user interface to allow theuser to register a specific participating entity as an authorizedbusiness partner. Providing the user interface may further includeproviding the user interface to allow the user to configure one or moretypes of transactions as permissible transactions between the user andthe authorized business partner. Providing the user interface furthercomprises providing the user interface to allow the user to configureone or more types of permissible queries submitted by the authorizedbusiness partner and directed at a particular identity database.

The method may further include: gathering information capable ofidentifying the user as well as information on authorized businesspartners of the user; and storing, in the database at the verifiedidentity engine, the identifying information, and information ofauthorized business partners. Gathering information capable ofidentifying the user the user may include: gathering identityinformation to attest to a purported identity of the user beforegranting access to the database at the verified identity engine.Gathering information on authorized business partners of the user mayinclude: gathering information on permissible transactions between theuser and each authorized business partner. Gathering information onauthorized business partners of the user may include gatheringinformation on permissible queries at a particular identity database byeach authorized business partner of the user.

Gathering information on authorized business partners of the user mayinclude gathering information on permissible data responses from aparticular identity database to each authorized business partner of theuser.

In one aspect, some implementations provide a method for generating atoken set that associate permissions and privileges with an identity,the method including: receiving, from a requester and at a computingdevice of a certification authority, a request for associating a firstindex of privileges and permissions with a foundation token, the firstindex specifically encoding the privileges and permissions of a firstsubscriber in accessing transactional data of the requester, the requestincluding the digital biometric that identifies a person and has beenissued to the requester by a trusted entity through a vetting process;extracting, from the request, the foundation token; determining that theextracted foundation token is valid; verifying that the requester is theperson identified by the foundation token based on a biometric of therequester matching the extracted digital biometric; in response todetermining that the foundation token is valid and verifying that therequester is the person identified by the foundation token, associatingthe first index of privileges and permissions of the first subscriberwith the foundation token; and providing, to the requester, thefoundation token associated with the first index of privileges andpermissions of the first subscriber, the foundation token enabling thefirst subscriber to access transactional data of the requester inaccordance with the first index of privileges and permissions.

Implementations may include one or more of the following features. Themethod may additionally include: receiving, from a requester and at thecomputing device of the certification authority, a request forassociating a second index of privileges and permissions with thefoundation token, the second index specifically encoding the privilegesand permissions of a second subscriber, different from the firstsubscriber, in accessing transactional data of the requester, therequest including the foundation token that identifies the person andhas been issued to the requester by the trusted entity through thevetting process; extracting, from the request, the foundation token;determining that the extracted foundation token is valid; verifying thatthe requester is the person identified by the foundation token based ona biometric of the requester matching the foundation token; in responseto determining that the foundation token is valid and verifying that therequester is the person identified by the foundation token, associatingthe second index of privileges and permissions with the foundation tokenof the second subscriber with the foundation token; and providing to therequester, the foundation token associated with the first index andsecond index of privileges and permissions, enabling the firstsubscriber and the second subscriber to access transactional data of therequester, respectively in accordance with the first index and thesecond index of privileges and permissions.

Determining that the foundation token is valid may include: verifyingthat the foundation token is issued by the trusted entity based on adigital characteristic of the foundation token uniquely identifying thetrusted entity. Determining that the foundation token is valid mayadditionally include: verifying that the person identified by thefoundation token is not listed in a negative-indicator database.Verifying that the requester is the person identified by the foundationtoken may additionally include: confirming that the requester is theperson identified by the foundation token by inquiring at a third-partycertification authority, different from the trusted entity, that therequester is the person identified by the foundation token.

Determining that the foundation token is valid may include: verifyingthat the foundation token has not expired or been revoked. Determiningthat the foundation token is valid may include: determining a score oftrustworthiness of the foundation token.

Providing the foundation token associated with the first index ofprivileges and permissions may include: transmitting data encoding thefoundation token associated with the first index of privileges andpermissions to the requester. Providing the foundation token associatedwith the first index of privileges and permissions may additionallyinclude: signing the foundation token with a signature of thecertification authority. Signing the foundation token may furtherinclude: watermarking the credential token with information uniquelyidentifying the certification authority.

Providing the foundation token associated with the first index ofprivileges and permissions may further include: encrypting thefoundation token with a digital key of the certification authority.Providing the foundation token associated with the first index ofprivileges and permissions may further include: generating additionaldata attesting to the integrity of the data encoding the foundationtoken.

Receiving the request may further include: receiving a foundation tokenissued by a government entity to the requester, the foundation tokenbeing a primary identity certificate that is issued after a vettingprocess conducted by the government entity on the person identified bythe foundation token.

In one aspect, some implementations provide a computer-implementedmethod for determining a trustworthiness of a requested transaction, themethod including: receiving, from a relying party, a request todetermine a trustworthiness of a particular transaction request, thetransaction request initially submitted by a user to access data managedby the relying party; based on the transaction request, summarizing theparticular transaction request into transactional characteristics, thetransactional characteristics devoid of source assets of thetransaction, the source assets including credential information of theuser, the credential information of the relying party, or informationcontent of the requested transaction; generating first machine-readabledata encoding transactional characteristics of the underlyingtransaction as requested, the transactional characteristics unique tothe particular transaction request; submitting a first inquiry at afirst engine to determine an access eligibility of the user submittingthe transaction request, the first inquiry including the credentialinformation of the submitting user, as well as the summarizedtransactional characteristics that is applicable only once to theunderlying transaction request; and receiving the access eligibilitydetermination from the first engine.

Implementations may include one or more of the following features. Themethod may additionally include: causing a second inquiry to besubmitted at a second engine to validate the particular transactionrequest based on the summarized transactional characteristics, whereinthe access eligibility determination factors in the determined validityof the particular transaction request.

The method may further include: logging, at a transaction databaseassociated with a second engine, an entry for the particular transactionrequest by storing the first machine-readable data encoding thetransactional characteristics of the particular transaction request.Storing the first machine-readable data encoding the transactionalcharacteristics of the particular transaction request may includereceiving confirmation that the first machine-readable data has beenstored at the transaction database associated with the second engine.Receiving confirmation may include receiving the confirmation that thefirst machine-readable data has been stored at the transaction databaseassociated with the second engine before submitting the first inquiry atthe first engine.

Storing the first machine-readable data encoding the transactionalcharacteristics of the particular transaction request may includestoring the first machine-readable data for only one retrieval query atthe transaction database. Storing the first machine-readable dataencoding the transactional characteristics of the particular transactionrequest includes storing the first machine-readable data for a retrievalquery within a time window at the transaction database.

The method may further comprise: determining the trustworthiness of thetransaction request initially submitted by the user based on thedetermined access eligibility of the submitting user; and notifying therelying party of the determined trustworthiness of the transactionrequest.

The method may further comprise: logging, at an identity databaseassociated with the transaction authentication engine, an entry of thereceived access eligibility determination as well as the determinedtrustworthiness of the transaction request.

The method may further comprise: in response to the relying partyproceeding with the requested particular transaction, generating secondmachine-readable data encoding transactional characteristics of theparticular transaction as consummated, the transactional characteristicsof the particular consummated transaction devoid of source assets of theconsummated transaction, the source assets including credentialinformation of the user, the credential information of the relyingparty, or information content of the transaction as consummated. Themethod may additionally comprise: logging, at an identity databaseassociated with the transaction authentication engine, an entry of theparticular consummated transaction by storing the secondmachine-readable data encoding the transactional characteristics of theparticular consummated transaction.

The method may further comprise: obtaining, from the receivedtrustworthiness determination request, credential information attestingto an identity of the submitting user; and generating an electroniccredential of the submitting user that is unique to the particulartransaction request initially submitted by the user. The method mayfurther include: causing the electronic credential to be stored at anidentity database associated with a first engine. The method of claim13, wherein causing the second inquiry to be submitted may furtherinclude: submitting data encoding the electronic credential at a secondengine. The method may further include: causing the second engine torender the access eligibility determination by verifying the electroniccredential at the identity database associated with the first engine.

Generating the first machine-readable data may further include:generating a bar code, an alphanumeric string, or a QR code encoding thetransactional characteristics.

The method may further include: prior to submitting the first inquiry,submitting an initial query at a second engine to establish a status ofthe relying party in processing transaction requests submitted by theuser. Submitting the initial query to establish the status may includesubmitting the initial query to determine if the transaction request ispermitted between the user and the relying party. Submitting the initialquery to establish the status includes submitting the initial query todetermine if the relying party is permitted to access identity databaseson behalf of the user. The method may additionally include: in responseto query results from the initial query, placing the relying party on awhitelist of the first engine. The method may additionally include: inresponse to query results from the initial query, placing the relyingparty on a review status.

In another aspect, some implementations may provide a machine-assistedmethod for a transaction database, the method including: receiving, froma first engine, machine-readable data encoding transactionalcharacteristics unique to a particular transaction request initiallysubmitted by a user at relying party, the machine-readable dataapplicable only once to the particular transaction request; receiving,from a second engine, an inquiry to validate the particular transactionrequest as well as to verify an identity of the user submitting theparticular transaction request at the relying party, the query includingtransactional characteristics of the transaction request, thetransactional characteristic unique to the particular transactionrequest; receiving, from a third engine, an authentication policy forthe relying party to validate the transaction request and to verify theidentity of the user; and based on the determined authentication policy,determining, by the authentication policy server, the validity of thesubmitted transaction request.

Implementations may include one or more of the following features.Determining the validity of the submitted transaction request mayinclude: comparing the received transactional characteristics againstdata contents of the machine-readable data. Comparing the receivedtransactional characteristics against data contents of themachine-readable data may include: retrieving the data contents of themachine-readable data stored at a transaction database for one-timeretrieval. Comparing the received transactional characteristics againstdata contents of the machine-readable data may include: retrieving thedata contents of the machine-readable data stored at a transactiondatabase for retrieval within a time window.

Determining the validity of the submitted transaction request mayinclude: verifying the identity of the user. Receiving themachine-readable data encoding the transactional characteristicsincludes receiving a bar code, an alphanumeric string, or a QR code.

The method may further include: based on the received inquiry, gatheringinformation identifying the relying party; and based on the gatheredinformation identifying the relying party, determining the correspondingauthentication policy.

The method may further include: based on the received inquiry, loggingverification activities requested by the relying party; and analyzingthe logged verification activities to determine usage statistics.Analyzing the logged verification activities to determine usagestatistics may further include: analyzing the logged verificationactivities to determine user behavior on an aggregate level. Analyzingthe logged verification activities to determine usage statistics mayfurther include: analyzing the logged verification activities todetermine user behavior on an individual level without comprisingidentity information of the user.

Some implementations may provide a machine-assisted method for anauthentication verification engine, the method including: receiving,from a first engine, an inquiry to determine an access eligibility of atransaction request submitted by a user to access data managed by arelying party, the inquiry comprising credential information of the useras well as machine-readable data encoding transactional characteristicsof the transaction request, the transactional characteristics unique tothe transaction request; based on the credential information of theuser, constructing a first query to validate the transaction request,the first query including the transactional characteristics unique tothe transaction request; submitting the first query to a transactiondatabase where transactional characteristics of transaction requestsinitially generated by the first engine are stored; and receivingvalidation results from the transaction database in response to thefirst query, the validation results determined based on, at least inpart, the transactional characteristics.

Implementations may include one or more of the following features.Constructing the first query may include: constructing the first queryto include the machine-readable data encoding transactionalcharacteristics of the transaction request, the machine-readable dataapplicable only once to the transaction request. Constructing the firstquery may include: constructing the first query to include themachine-readable data encoding transactional characteristics of thetransaction request, the machine-readable data valid for retrieval queryat the transaction database within a time window.

The method may further include: determining access eligibility based on,at least in part, the received validation results. The method mayfurther include: submitting the second query at an identity database incommunication with the authentication verification engine. The methodmay further include: verifying the identity of the user submitting thetransaction request based, at least in part, on query results from theidentity database.

The method may further include: configuring a protocol for communicationwith the identity database, the protocol being determined by a secondengine prescribing data access rights by the relying party at theidentity database. The method may further include: prior to submittingthe first query, submitting an initial query at a second engine toestablish a status of the relying party in processing transactionrequests submitted by the user. Submitting the initial query toestablish the status includes submitting the initial query to determineif the transaction request is permitted between the user and the relyingparty. Submitting the initial query to establish the status may includesubmitting the initial query to determine if the relying party ispermitted to access identity databases on behalf of the user.

The method may further include: in response to query results from theinitial query, placing the relying party on a whitelist of the firstengine. The method may further include: in response to query resultsfrom the initial query, placing the relying party on a review status.The method may further including gathering the information identifyingthe user by: calling a method individually encapsulated in thetransaction request; receiving a return value as a result of calling themethod; and retrieving the information identifying the user in thereceived return value. The method may further include: based on thegathered information, constructing a second query to verify an identityof the user submitting the transaction request.

The system includes one or more processors and instructions embedded ina non-transitory machine-readable medium that are executable by the oneor more processors. The instructions, when executed, are configured tocause the one or more processors to perform the above described actions.The default position is not to use any external databases, but thesystem could be configured to perform a database check if needed.

The details of one or more aspects of the subject matter described inthis specification are set forth in the accompanying drawings and thedescription below. Other features, aspects, and advantages of thesubject matter will become apparent from the description, the drawings,and the claims.

DESCRIPTION OF DRAWINGS

FIG. 1 is a diagram showing an example integrated identity managementsystem according to some implementations.

FIG. 2A shows an example workflow for determining a trustworthiness of atransaction request submitted by a user at a participant entityaccording to some implementations.

FIGS. 2B to 2D are flow charts showing example workflows for determininga trustworthiness of a transaction request.

FIG. 3 is a diagram showing an example integrated identity managementsystem constructed to perform perishable symbology.

FIG. 4 is a diagram showing another example integrated identitymanagement system constructed to perform perishable symbology.

FIG. 5 is a diagram showing another example integrated identitymanagement system according to some implementations.

FIGS. 6A and 6B show another example workflow for determining atrustworthiness of a transaction request submitted by a user at aparticipant entity according to some implementations.

FIG. 7 shows yet another example workflow for determining atrustworthiness of a transaction request submitted by a user at aparticipant entity according to some implementations.

FIG. 8 is a diagram showing yet another example integrated identitymanagement system constructed to perform perishable symbology.

FIG. 9A is a diagram illustrating examples of a biometric core platformaccording to some implementations.

FIG. 9B is a diagram illustrating example methods of systeminteroperability and compatibility according to some implementations.

FIG. 9C is a diagram illustrating interface architecture according tosome implementations.

FIG. 10A is a diagram illustrating an example interface stack for atransaction authentication engine according to some implementations.

FIG. 10B is a diagram illustrating an example architecture for atransaction authentication engine according to some implementations.

FIG. 11A is a diagram illustrating an example interface stack for anauthentication verification engine according to some implementations.

FIG. 11B is a diagram illustrating an example architecture for a anauthentication verification engine according to some implementations.

FIG. 12A illustrates a token management architecture.

FIG. 12B illustrates another token management architecture.

FIG. 13 shows an example process for a certificate authority to interactwith a user according to some implementations.

FIG. 14 shows an example process for a user to request sets ofprivileges and permissions to be added to a foundation token of theuser, according to some implementations.

Like reference symbols in the various drawings indicate like elements.

DETAILED DESCRIPTION

Countless risks associated with identities may be present intransactions being conducted on a daily basis. With the advent of theInternet, comes the age of e-commerce in which on-line transactions mayreplace face-to-face transactions. The sheer volume and complexity ofthese on-line transactions may give rise to a digital world fraught withperil, including, for example, identity theft, identity fraud, spoofing,phishing, etc. Notably, such risks may not be new in the Internet age,although the Internet may have amplified such risks. As the societymoves towards cloud computing, more and more identity databases maybecome available. Identity data in some databases may be more reliableand robust than others, based on history or tradition. In someimplementations, identity data in identity databases administered by adepartment of motor vehicles (DMV) may be leveraged to verify anidentity of a recipient party engaged in, for example, a financialtransaction. Additional identity databases may provide collaborativeconfirmation attesting to the authenticity of a purported identity. Someimplementations as disclosed herein may provide servers and engines topower an integrated identity management system, in which the servers orengines act in concert with each other to verify the authenticity of anidentity. For example, the system may provide access control so that aconsumer can prescribe the parties authorized to verify the identity ofthe consumer as well as the scope of the authorized power. Theenvisioned identity management system may include fee for servicearrangements to enforce business rules for accessing to the system. Forexample, business may purchase a subscription plan that provides variouslevels of access with a commensurate fee. The identity management systemmay provide application interfaces to interconnect with other identitymanagement systems to extend services to consumers and providers. At thesame time, consumers and providers may opt-in or opt-out of the system.Deployment of the integrated identity management system may enhanceconfidence in the transactions being conducted between parties andhence, promote commerce.

FIG. 1 is a diagram showing an example integrated identity managementsystem according to some implementations. An identity management systemmay be implemented to determine the trustworthiness of a transactionrequest submitted by a user at, for example, a financial institution.The transaction requested may include an electronic transaction and therequest may be submitted on-line. In one analogy, the identitymanagement system disclosed herein may function as a hierarchy oflayers, similar to a layered communications protocol for packetswitching communications network. Each layer in the hierarchy may engageone stage of verification in reaching a final disposition oftrustworthiness.

As shown in FIG. 1, data request 102 may represent a transaction requestsubmitted by a user in the capacity of a consumer. The consumer mayinclude an individual consumer or an organizational entity. Exampleorganizational entities may include a corporation, a bank, a governmentagency, etc. The transaction request may be submitted at a variety ofplaces, including, for example, a financial institution, a merchant, aservice provider, a government agency, etc. Indeed, the Internet mayallow a consumer to conduct virtually all commercial, business, andsocial transactions on-line.

The requested on-line transaction may access data owned by the recipientof the request. The recipient of the requested on-line transaction mayinclude financial institutions, merchants, service providers, as well asgovernment agencies. Example financial institutions may include anyorganization engaged in financial transactions, banks, securitiesbrokerage firms, trust administrators, retirement plan administrators,college saving plans administrators, etc. The recipient merchant mayinclude any vendor attempting to sell merchandise on-line. The recipientservice provider may include any entity that charges a fee for aservice, including, for example, accounting firms, consulting firms,etc. The recipient government agency may include any government agencyor commission at the state or federal level, including, for example,social security agency, unemployment agency, taxation agency, departmentof human and health services and its state counterparts, department ofmotor vehicles, etc.

In response to the received data request, the recipient entity mayconduct a due diligence verification to determine the trustworthiness ofthe submitted transaction request. The due diligence verification mayinclude verifying that the user submitting the transaction request isthe person he or she purports to be. The due diligence verification mayalso include verifying whether the transaction requested is permissiblebetween the recipient entity and the user. Unless the due diligenceverification proves that the submitted transaction request istrustworthy, the recipient entity may not allow access to the data beingrequested.

To conduct the due diligence verification of a received transactionrequest, the recipient entity may submit inquiries to the disclosedidentity management system. In submitting the verification inquiries,the recipient entities become participant entities in the identitymanagement system. Pictorially, the participant entities are representedby data request originators 1 to 5 shown in FIG. 1. For each transactionrequest received at data request originators 1 to 5, inquiries may besubmitted, via respective interfaces, to transaction authenticationengine (TAE) 122. The inquiries may elicit respective responses from theTAE 122 regarding a trustworthiness disposition of the requestedtransaction.

For the TAE 122 to process the submitted inquiries from data originators1-5, the respective data owner may provide discrimination methods forthe TAE 122. The discrimination methods may enable context-dependentprocessing of the transaction request for which the trustworthiness isbeing investigated. In some configurations, the trustworthinessinvestigation may be performed in accordance with varying thresholdlevel requirements that are commensurate with the character of theunderlying transaction, trust level of each electronic proof ofidentity, as well as the custom policies of the participant entitiesmanaging the data targeted by the transaction being requested. Forexample, discrimination method may include threshold level of thetransaction amount to trigger increased scrutiny. As an illustration,financial transaction over the amount of $500 may automatically triggerincreased scrutiny and if the amount is over $100,000, then more thanone source may be consulted to verify the identity of the requestor.Such discrimination method may correspond to the discrimination layer104 illustrated in the hierarchy in FIG. 1.

Thus, TAE 122 may function as an infrastructure apparatus to determinewhether the transaction request is sufficiently trustworthy for therecipient entity to process the requested transaction.

The determination of trustworthiness of the transaction request mayincorporate validating electronic proof of identity accompanying thesubmitted transaction request. The electronic proof of identity may becompared against an identity database during the validation process. Ingeneral, the identity proof may become available only after a vettingprocess at an authoritative institution, such as the department of motorvehicles (DMV), the state department, etc. The vetting process mayadditionally comply with legislative directives, such as the REAL ID Actor the PASS ID Act, to boost secure identity documentation. Exampleselectronic proof of identity may include a digital identificationdocument, such as, for example, a digital driver's license, a digitalpassport, a digital social security card, a digital medicare/Medicaidcard, etc. The electronic proof of identity may also include a biometricin digital form, such as an electronic signature, a digital fingerprint, a digital palm print, a digital iris scan, a digital retina scan,or even a DNA digitally captured. The electronic proof of identity maybe subject to additional encryption (for example, by the holder'sprivate key) to further prevent tampering. Moreover, revocation orreplacement of lost/stolen electronic proof of identity may be instantlyeffective at the identity database of the authoritative source. Hence,lost/stolen electronic proof of identity can be recognized duringverification once the authoritative source has been updated. As aresult, possession of a verifiable electronic proof of identity mayestablish a prima facie showing that the holder is the person identifiedby the electronic proof of identity.

The next layer is the access methods layer 106. The access methods layer106 generally refers to a work flow including protocols for verifying,for example, the electronic proof of identity, identity databases tocompare against, as well as user authorization of business partners toquery an identity database to verify the user's identity. As disclosedherein, access methods layer 106 may be interchangeably referred to asthe work flow layer 106.

The next layer is the access policies layer 108 which generally includesmacroscopic and microscopic policies for participant entities to queryan identity database. The access policies may include a subscriptionstatus of a particular participant entity to query a specific identitydatabase, usage metering of a particular participant entity to query aspecific identity database, accounting for accessing a specific identitydatabase by a particular participant entity, load balancing of serversassociated with querying a specific identity database, etc.

In one configuration, an authentication policy server 128 may host adatabase to track the subscription status of participant entities.Depending on the underlying identity databases, the subscriptiondatabase may include the current subscription status of a particularparticipant entity. The current subscription status may reflect thelevels of access to a particular identity database that a participantentity has paid for. For example, participant entities may pay for aregular access that provides a monthly access quota. The regular accessmay include a labeled access bandwidth guarantee that may include (i) afloor level of the number of queries to the identity database submittedwithin a quantum of time, such as, for example, per minute; or (ii) afloor level of the number of responses received from the identitydatabase per quantum of time, such as, for example, per minute.

In comparison, a basic access may include a labeled access bandwidthguarantee that includes (i) a ceiling level of the number of queries tothe identity database submitted within a quantum of time, such as, forexample, per minute; or (ii) a ceiling level of the number of responsesreceived from the identity database per quantum of time, such as, forexample, per minute. Not surprisingly, the subscription fee is reducedfor basic access.

Similarly, a premium access may be a step upward from the regularaccess. For example, the premium access may include a labeled accessbandwidth guarantee with higher floor levels in the number of queries tothe identity database submitted by the paying participant entity orhigher floor levels in the number of responses to be received by thepaying participant entity from a particular identity database.

In a way, the labeled access bandwidth guarantee may be similar toadvertised access bandwidth as provided by cable or phone companies.Indeed, the labeled access bandwidth guarantee may be listed in suchmetrics as the amount of information or data to or from a particularidentity database for each payment level. In short, the participantentities each get what they paid for. A non-paying participant entitymay not have the identity management system to submit query to theidentity database and may not receive responses from the identitydatabase either.

The level of access may be measured in metrics other than a merebandwidth. For example, the level of access may also be measured inthroughput terms. The throughput terms may track the total amount ofinformation, e.g., number of bytes, transmitted between a participantentity and an identity database. The throughput terms can be morefine-grained than the total data in bidirectional communication. Forexample, the throughput terms may include the number of queries (or theamount of data encoding such queries) submitted by a participant entityto an identity database, the number of responses (or the amount of dataencoding such responses) received by a participant entity from anidentity database, etc. Hence, the level of access according to someimplementations disclosed herein may be measured in terms similar to themetrics adopted by water, sewage, gas, or electricity companies.

Moreover, the level access may include duration of connection time.Connection time may include the period of time during which aparticipant entity is engaged in actual communication with an identitydatabase. The connection time metrics may be enforced by simple timersinstalled on the authentication policy server 128. The connection timemetric according to some implementations may resemble the metrics usedby phone companies or internet café. For example, if an access planaccording to some implementations may allocate a time quota for a payingparticipant entity to access the identity database during a peak-time,for example, between 9 am and 5 pm local time where the identitydatabase. During off-peak time, however, the paying participant entitymay be given more time quota to communicate with the identity database.In some instances, the paying participant entity may even communicateconstantly during off-peak time, much like unlimited access duringoff-peak time as used by certain phone companies.

To enforce a subscription plan, the authentication policy server 128 maymeter the usage of a particular database by counting the number ofqueries transmitted to the identity database, the amount of datatransmitted to the identity database in association with the queries,the number of responses received by the participant entity, the amountof data received from the identity database in association with theresponses to queries.

Participant entities may choose a plan based on actual usage. Actualusage of a particular participant entity may be determined by meteringas discussed above. Based on the metered usage, accounting may beperformed to determine a monetary cost to the particular participantentity. For participant entities on a plan with a cost quota, thedetermined monetary cost may be compared against the quota in real-time,as the queries and responses are being communicated back and forth. Whenthe cost incurred from actual usage approaches the cost quota, an alertmay be sent to the participant entity to inform the entity of thestatus. If the cost incurred reaches the quota and no additionalsubscription payment is received from the participant entity, theparticipant may no long receive service from the transactionauthentication engine 122.

The next layer is the database trusted source layer 110, which maycorrespond to authenticated verification engine (AVE) 128 in someimplementations. AVE 128 may interface directly to identity databasesmaintained at authoritative sources. The identity data layer 112 maycorrespond to databases 130-144. As shown in FIG. 1, the identitydatabases 130-142 administered by authoritative sources such as agovernment agencies. A government agency mandated to provide service toindividual citizens may be an authoritative source in maintaining anidentity database hosting identity information of the individualcitizens being served. Example government agencies may include theDepartment of State, the Department of Homeland Security/US Citizenshipand Immigration Services, the Department of Health and Human Services,the Internal Revenue Service, the Social Security Administration, theDepartment of Motor Vehicles at each state, etc. Sovereign nations otherthan the US may have comparable agencies or administrations orcommissions that function similarly to the US counterparts in servingindividual citizens.

Moreover, identity database could be from a non-government authoritativesource. As illustrated in FIG. 1, third party trusted system 144 mayhouse additional identity databases which may be queries by AVE 126. Insome implementations, third party trusted system may includenon-government entities that may be trusted by history or tradition inserving consumers. Example non-government entities may includequasi-government agencies such as professional organizations ofindividual members and membership may require a thorough applicationprocess to check the applicant's background (e.g., credit history,employment history, educational background, criminal record, etc.).Example professional organization may include the American BarAssociation, the state bar of each jurisdiction, a professional tradeassociation, a professional sport association, an alumni association,etc. Example non-government entities that may house identity databasesmay additionally include financial institutions with a long history ofserving average consumers, such as mortgage institutions, banks, creditunions, credit card companies, etc. More recently, on-line socialnetworking entities may also house identity databases with a qualifieddegree of authority. Such on-line social networking entities may includeLinkedIn, MySpace, Twitter, Facebook, etc.

The identity data stored in databases 130-142 and third-party trustedsystem 144 may be acquired after a vetting process, corresponding toacquisition methods layer 114. The vetting process for a governmententity may include a lengthy application process to verify anapplicant's identity. For example, when applying for a driver's license,a state DMV typically require the applicant to present a valid driver'slicense from another jurisdiction, or a valid passport, or a validpermanent resident card. The applicant may be further required toprovide proof of residence, including utility bills, cable bills, phonebills, etc. to show that the applicant indeed resides in the intendedjurisdiction. Sometimes, the applicant may need to provide proof ofemployment as well. The applicant may be additionally required to passvision test or a driving test. Once the applicant has passed the tests,biometric information identifying the applicant may be taken from theapplicant, including, for example, a portrait of the applicant, a fingerprint of the applicant, a signature of the applicant, etc. Otherpersonally identifiable information, such as hair color, eye color,blood type, birth date, etc., may also be collected from the applicant.The vetting process may include authenticating the applicant andperforming background check on the applicant. Successful completion ofthe vetting process may establish a prima facie presumption of theapplicant's identity as recorded in the identity database.

As to the non-government entities housing identity databases, acomparable vetting process may be instituted to establish a prima faciepresumption of the member's identity. For example, professionorganizations may require applicant to complete a thorough screeningprocess before the applicant can be admitted as a member. Additionally,annual membership dues and compliance with professional conduct may berequired to maintain membership. The screening process, along withmembership obligations, may filter out unqualified individuals ormembers not in good standing. In doing so, the trustworthiness qualityof the identity data of the active members may be maintained.

User 202 may desire to engage in a transaction with participant entity204. The transaction may be a financial transaction, such as,transferring funds between financial accounts, making on-line payments,viewing account balance, etc. The transaction may be administrative,such as, for example, updating contact information, updating residentialaddress, updating employment history, updating employment status,updating insurance coverage information, updating educationalbackground, etc. The transaction request may be submitted (220) in avariety of ways. The transaction may be submitted on-line through acomputer of user 202 or a mobile device of user 202. The transactionrequest may also be submitted at a branch office of the participantentity (e.g., a financial institution, a government agency, etc.) andmay be processed by a machine apparatus at the branch office (e.g., akiosk, an automatic teller machine, etc.)

User 202 may include an individual user, an organizational user (e.g., acorporation, a non-profit organization, a government agency, etc.).Participant entity 204 may be any entity subscribing to the integratedidentity management system as disclosed herein. Participant entity 204may include a business entity (e.g., a person, a corporation, apartnership, a sole proprietary, etc.), a non-profit entity (e.g.,professional organizations, educational institutions, etc.), agovernment entity (e.g., a government entity at the state or federallevel, etc.).

The requested transaction may attempt to access data managed by theparticipant entity 204. When participant entity 204 receives thetransaction request, participant entity 204 may need to authenticatethat user 202 submitting the request is who user 202 purports to be. Inthe Internet age, simple authentication based on user name and passwordmay not suffice with the advent of Cloud computing and the trend towardsthe Big Data. In fact, simple on-line identities including user name andpassword may be subject to identity theft and identity fraud. A recentsurvey revealed that identity theft in the United States rose to athree-year high in 2012, with more than 5 percent of the adultpopulation, or 12.6 million people, falling victim to such crimes. Thenumbers are up from 4.9 percent in 2011 and 4.35 percent in 2010. Theincidence of identity theft is only expected to rise. To mitigate therisks arising from identity theft in the context of e-commerce, someimplementations, as disclosed herein, function towards an integratedidentity management system in which participant entities, assubscribers, may leverage the identity information at identity databaseslocated elsewhere. A vetting process may be in place as a gatekeeper toallow verified identity information of individual users to enter theidentity databases. For example, by history and tradition, identitydatabases at the Department of Motor Vehicles may serve as theauthoritative source of identity information because the identityinformation in the identity database of the DMV have been verified andvalidated during the background checking and on-site applicationprocess. The ubiquitous internet may provide a unique opportunity toleverage the authority of identity information in the identity databaseto validate user-submitted transaction requests.

As illustrated in FIG. 2, participant entity 204 may submit a request tovalidate (221). The request to validate may be submitted at thetransaction authentication engine 122. The request to validate may besubmitted by participant entity 204 in response to a transaction requestreceived from user 202. The purpose of the request to validate is to getan opinion as to the trustworthiness of the transaction request assubmitted by user 202. To reach a disposition on the trustworthiness, asrequested, TAE may conduct two inquiries. First, whether the user 202submitting the transaction request is indeed what user 202 purports tobe. Second, whether participant entity 202 is entitled to submit therequest to validate.

TAE 122 may submit the first inquiry to authentication verificationengine 126 (222). The first inquiry may include identity information ofuser 202. Such identity information may be obtained from user 202 whensubmitting the transaction request at participant entity 204. In someimplementations, user 202 may present an identification document at thetime of submitting the transaction request. For example, user 202 mayshow a driver's license to a reader device, such as a scanning deviceattached to a mobile device of the 202. Other forms of identificationdocument, such as a passport, a national identification card, a socialsecurity card, a medicare/Medicaid card etc. The identification documentmay also be a digital identification document, issued by a governmentagency through the same rigorous vetting process. The digitalidentification document may or may not be scanned by a reader device. Insome implementations, data encoding the digital identification documentmay be beamed to a reader device. In some implementations, data encodingthe digital identification document may be received along with thetransaction request at the participant entity 204. Watermarking featuresmay be present in the identification document to deter counterfeiting ortampering.

AVE 126 may interface to an authoritative identity database, such as anidentity database at a department of motor vehicles, the statedepartment, the social administration, the department of human andhealth services, etc. AVE 126 may submit a query (223) to identitydatabase 210 in an effort to compare the identity information of user202 against identity database 210. AVE 126 may compute an authenticityscore indicating the relative authenticity of the identity informationof user 202. In other words, the authenticity score may numericallyattest to the identity of user 202. Query results may be received fromidentity database. In some implementations, a 1 to 1 mapping result maybe returned from the identity database in response to the query. Thequery results may also be relayed by AVE 126 to TAE 122, along with thecomputed authenticity score.

Either subsequently or concurrently, TAE 122 may submit a second inquiryat authentication policy engine 128 (226) to ascertain whetherparticipant entity 204 is entitled to submit the request to validate.APS 128 may maintain a database to track the subscription status of eachparticipant entity. If participant entity 204 has not subscribed to theservice or if the participant entity 204 has an expired subscription,then participant 204 may not have the currency to support the request tovalidate. Moreover, the database at APS 128 may also include thesubscription plan for each subscribing participant entity. As discussedabove, the subscription plan may impact the time and manner in which aparticipant entity may access a particular identity database.Furthermore, APS 128 may enforce a set of business rules for eachsubscribing participant entity. For example, a participant entity mayonly submit request to validate and access the identity database duringspecified times, from specific IP addresses, etc. The business rules mayprescribe the scope of services that each participant entity may obtainfrom a particular identity database. APS 128 may enforce the businessrules.

Based on the subscription status of the participant entity 204 and theprescribed business rules associated with the participant entity 204,APS 128 may compute a validity score for the participant entity 204 toaccess the identity database. By submitting the request to validate atransaction request, participant entity may attempt to access aparticular identity database. In response to the second inquirysubmitted by TAE 122 to APS 128, the computed validity score may bereturned to TAE 122 (227). The validity score may reflect numericallythe relative degree of validity for the participant entity 204 to accessthe identity database when the participant entity 204 requested TAE 122to, for example, verify the identity of the user requesting atransaction at the participant entity.

Based on the computed authenticity score and the validity score, TAE 122may reach a disposition on the trustworthiness of the transactionrequest. The determination may also factor in the specific query resultsreceived from the identity database in response to the submitted query.The disposition results may be relayed to participant entity 204 (228).If the disposition of trustworthiness is favorable, then participantentity 204 may proceed with the requested transaction and provide user202 with the transaction results (229). If, however, the disposition oftrustworthiness is not favorable, then participant entity 204 may notproceed with the requested transaction. Instead, participant entity 204may provide an error message to user 202 indicating that the requestedtransaction failed to go through.

FIGS. 2B to 2D show respective example flow charts for TAE 122, AVE 126,and APS 128 according to some implementations. The engines illustratedby TAE 122, AVE 126 and APS 128 may include a server computer having atleast one processor and memories. The engines may also include a serverprocess on a computer. The process may have at least one thread and mayengage in inter-process or inter-thread communications.

In FIG. 2B, an example TAE 122, according to some implementations, mayreceive, from a participant entity, a request to determine atrustworthiness of a transaction request (230). As discussed above, thetransaction request may be submitted by a user in an attempt to accessdata managed by the participant entity.

In response, TAE 122 may submit a first inquiry at an authenticationverification engine (AVE) 128 to determine an authenticity statusattesting to a purported identity of the user (232). Thereafter, TAE 122may receive a response from AVE 126 (234). The response may include acomputed authenticity score indicative of the relative authenticity ofthe purported identity of the user.

In some implementations, based on the computed authenticity score, TAE122 may determine the trustworthiness of the transaction request beingsubmitted by the user (240). For example, when the participant entity204 merely seeks a second identity proof of user 202 at an identitydatabase and participant entity 204 has access right to eventually queryat the identity database, then a response from TAE 122 either confirmingor refuting the user's identity may be sufficient. An example scenariomay be when user 202 submits a transaction request to purchase alcoholfrom participant entity 204. In addition to take payment for the alcoholproduct, local regulations may require participant entity to confirmthat user 202 is indeed over, for example, 21 years of age. Anidentification document of user 202 may be presented by user 202 alongwith the transaction request. The identification document may include,for example, a driver's license, a passport, a national identificationcard, etc. The transaction request may include an on-line transactionrequest. A copy of the identification document may be may be forwardedto the TAE 122. In turn, TAE 122 may query identity database, throughAVE 126, based on the identification document. If query results confirmthat the identification document is authentic and has not been tamperedwith, and that user 202 is over 21 years of age, AVE 126 may return afull authenticity score to TAE 122. TAE 122 may subsequently determinethat the transaction request is trustworthy, as submitted by user 202.Thereafter, TAE 122 may notify the participant entity 204 of thedetermined trustworthiness of the transaction request (242).

Similar example scenarios may include the purchase of guns, controlledsubstances, etc. In these example scenarios, identity databases may bequeried to ascertain whether user 202, as the requestor, may havecriminal record that may impact the requestor's ability to buy suchitems. Example identity databases to be queried may include, forexample, the registered sex offender registry.

Generally, the authenticity score may amount to a matter of degree ofconfidence as to the authenticity of a purported identity. The requisiteauthenticity score may vary, depending on the application underneath.For example, for transactions involving a financial sum of under $500, alower degree of match authentication level may be sufficient. While forapplications involving any purchase of controlled substances, a higherdegree of confidence may be needed.

In some implementations, TAE 122 may submit a second inquiry atauthentication policy engine (APS) 128 to determine a scope of rightpossessed by the participant entity 204 to access a particular identitydatabase (236). As discussed herein, the participant entity may attemptto verify the user's identity by querying, for example, through AVE 126,an identity database as an authoritative source. Subsequent tosubmitting the second inquiry, TAE 122 may receive a reply from APS 128(238). The reply including a computed validity score indicative of thescope of the right to access the particular identity database.

TAE 122 may also receive query results from a particular identitydatabase, for example, through AVE 126 in accordance with the scope ofright for the participant entity to access the particular identitydatabase. The query results may be in response to a query about theidentity of a user submitting a transaction request at the participantentity. APS 128 may administer business rules to regulate the manner inwhich such query results may be received by TAE 122. These businessrules may be entity specific and may be at various granularity levels.In one configuration, the business rules may have special provisions forinsurance companies to access a user's medical history. Some businessrules may limit query results (in response to queries on employmenthistory) to employment data of the user during the past three years.Other business rules may prescribe the quantity of received queryresults depending on when or where queries are submitted. For example,during busy times, the prescribed quantity may be more limited. If thequeries are submitted from geographically more distant addresses, thequery results may be more limited in content or quantity.

In implementations where the TAE 122 submits a second inquiry to APS 128to determine a scope of right possessed by the participant entity 204,the second inquiry may be submitted simultaneously along with the firstinquiry, or sequentially. The second inquiry may be submitted ahead ofthe first inquiry and if participant entity is not entitled to use theintegrated system to query a particular identity database, the firstinquiry may not need to be submitted. In return for the submitted secondinquiry, TAE 122 may receive a computed validity score from APS 128. TAE122 may make a determination of trustworthiness of the transactionrequest being submitted (240) and may factor in both the authenticityscore and the validity score in the determination.

After making the determination, TAE 122 may notify the participantentity 204 of the determined trustworthiness of the transaction request(240). If the determination is unfavorable, TAE 122 may also notifyparticipant 204 of the reasons behind the unfavorable determination,including, for example, subscription expired, quota exceeded, etc.

The contents of the query results, when received at TAE 122, may beconsidered by TAE 122 during the determination of the trustworthiness ofthe transaction request. As discussed, the determination may also factorin the authenticity score quantitatively attesting to the purportedidentity of the user submitting the transaction request as well as thevalidity score indicative of the right possessed by the participantentity to use the integrated identity management system to verify theidentity of the user. For example, user 202 may submit a transactionrequest to obtain a homestead tax exemption in the jurisdiction to whichuser 202 is transferring. In the illustrative example, the transactionrequest may be submitted at the department of taxation of thejurisdiction, which may operate in the capacity of participant entity204. The department of taxation may use the integrated identitymanagement system to query, for example, an identity database at the DMVof the jurisdiction to ascertain the current residential address of user202. TAE 122 may coordinate the verification process by submitting aninquiry at AVE 126, which may interface with an identity databaseadministered by the DMV of the jurisdiction. Through coordination of TAE122, AVE 126 may submit query into the identity database at the DMV. Thereturned query results may be forwarded by AVE 126 to TAE 122. Indetermining the trustworthiness of the requested transaction to obtainan tax exemption status, TAE 122 may review the residential address asreturned from the DMV identity database to ascertain, for example,whether user 202 may qualify for the applied-for exemption status,whether user 202 has been residing for any requisite time, whether theaddress is within an exemption zone, etc. Thus, the determination on thetrustworthiness of the exemption status application, as requested, mayhinge on the combined factors of the query results, the authenticityscore, and the validity score. The results of the trustworthiness may bereturned to the department of taxation, along with the residentialaddress from the query results. In some cases, TAE 122 may query DMVs ofseveral jurisdictions to obtain a residential history of user 202. Thetrustworthiness determination may factor in the entire residentialhistory. The department of taxation receiving the homestead statusapplication may receive both the trustworthiness determination and theresidential history.

In another illustrative example, user 202 may request a transaction tobid for a job opening at a hiring employer. User 202 may submit a proofof identity, such as, for example, an identification document, alongwith the job application. In this illustrative example, the hiringemployer, be it a private corporation or government entity, may operatein the capacity of participant entity. Hiring employer may use theintegrated identity management system to query, for example, an identitydatabase at the department of labor to obtain the employment history ofuser 202. If the obtained employment history matches the data asdisclosed by user 202, as the applicant, full credit of trustworthinessmay be issued by TAE 122. If, however, the obtained employment historydoes not match the data disclosed by user 202, the trustworthinessdetermination may become more nuanced. In some cases, if there areundisclosed gaps in the employment history from department of labor,then the trustworthiness determination may become unfavorable. In somecases, if the discrepancies appear as minor spelling variations, thetrustworthiness may be considered intact. In some cases, when thetrustworthiness becomes difficult to determine, then TAE 122 may causethe AVE 126 to submit further queries at other identity databases, suchas, for example, income tax record at the internal revenue service (oran equivalent foreign agency, such as Revenue Canada). Income taxrecord, such as, W2 forms or 1099 forms for user 202 may be obtainedfrom the taxation agencies as a surrogate of the employment historydata. If the income tax record, as the returned query results, candemonstrate that user 202 has paid income taxes commensurate with thedisclosed employment history data during the questionable years, thenthe trustworthiness of the application may still receive almost fullcredit. If no commensurate tax record may be found in the returned queryresults, the trustworthiness may be deemed low. As discussed herein, thedetermined trustworthiness and the query results returned from one ormore identity databases, may be communicated to user 202.

In some implementations, the received query results may be storedtemporally at TAE 122. The temporary storage may amount to a form ofcaching such that TAE 122 may look up the temporarily stored queryresults before querying, through AVE 126, the particular identitydatabase. The temporarily stored query results may be accessed inaccordance with the business rules regulating the scope of access rightas discussed above. Further, the business rules may allow a participantentity to use the temporarily stored query results for a specific timeperiod during which the temporarily stored copy may be consideredcurrent (as compared to stale). Moreover, TAE 122 may institute cachingpolicies to coordinate with the particular identity database regardingupdates in the identity data for user 202. For example, TAE 122 mayestablish an update status list for the identity data for each userqueried before. TAE 122 may then receive a notification from theparticular identity database when the identity data for one of thelisted user has been updated.

Further, TAE 122 may obtain an authentication policy from theauthentication policy engine 128 functioning as a server. Theauthentication policy may govern communication between the transactionauthentication engine and the authentication verification engine. Forexample, the authentication policy may include prescribed communicationsprotocols between TAE 122 and AVE 126 as well as between AVE 126 andidentity database 210. The communication protocols may be sessionspecific or subscription dependent. TAE 122 may then configure and setup the agreed-on communication protocol to engage in data communicationwith AVE 126, and through AVE 126 to identity database 210. For example,TAE 122 may configure the communication protocol according to thesubscription of the participant entity. In other words, TAE 122 mayenable a participant entity to obtain as much as access to database 210through AVE 126 as the participant entity has paid for. Furthermore, TAE122 may set up the encryption protocol to transmit data from TAE 122 toAVE 126 as well as the decryption protocol to decode data received fromAVE 126.

Turing to FIG. 2C, an example flow char for AVE 126 is shown. AVE 126may receive, from TVE 122, an inquiry regarding a user submitting atransaction request to access data managed by the participant entity(244). The inquiry may include information identifying the user. AVE maygather the information identifying the user (246). For example, togather the information from the transaction request, AVE 126 may call amethod individually encapsulated in the transaction request. Theencapsulation may mitigate the risk for AVE 126, or other components ofthe integrated identity management system, to leak the identifyinginformation, even inadvertently. The encapsulation may be consistentwith, for example, object oriented programming (OO) paradigm and may beimplemented in a variety of programming languages, such as, for exampleJAVA, C++, or any scripting language with compatible with the OOparadigm. AVE 126 may then receive a return value as a result of callingthe method and the information identifying the user may be retrievedfrom the return value.

The information identifying the user may include information encoding abiometric of user 202, such as, for example, a finger print, a palmprint, a written signature, etc. The information identifying the usermay also include personally identifiable information of user 202.Example personally identifiable information may include name, birthdate, address, height, weight, eye color, hair color, marital status,etc. Information identifying the user 202 may also include user-name andpassword pair for user 202 to access an on-line account. Informationidentifying user 202 may be obtained from an identification document ofthe user. In some implementations, user 202 may attach a copy of anidentification document along with the transaction request. The attachedidentification document may include a copy of the driver's licensescanned by a reader device when user 202 was submitting the transactionrequest. In one configuration, the attached identification document mayinclude a digital identification document, such as, for example, adigital driver's license. Information encoding the digitalidentification document may be beamed in when user 202 was submittingthe transaction request.

Based on the information identifying the user, AVE 126 may construct aquery to verify an identity of the user who has requested thetransaction (248). AVE 126 may then submit the query to a particularidentity database in communication with AVE 126 (250). As disclosedherein, the identity database may be administered by an authoritativesource, such as the department of motor vehicles, the department ofstate, etc. Each of the authoritative sources may administer a rigorousvetting process to check the background of an individual before theidentity data of the individual can be entered into the identitydatabase. In some implementations, third party identity databases may beresorted to. These third party identity databases may have a qualifieddegree of authority. For example, social networking sites like Facebookor Linked-in may have an identity database for each user. Identity datain these databases may be less reliable than comparable identity datamaintained at traditionally authoritative sources, such as the DMV.Identity data in less reliable identity databases may be treated withmore scrutiny.

AVE 126 may then receive a reply from the identity database in responseto the query (252). In some implementations, the reply may be a 1:1mapping in which the top match is returned. In other implementations,the reply may be a 1:n mapping in which the top n matches are returned.

Based on the received reply, AVE 126 may compute an authenticity scorequantitatively attesting to the identity of the user who has requestedthe transaction (254). AVE 126 may then provide the computedauthenticity score useful for determining a trustworthiness of thetransaction request.

When engaging a particular identity database, AVE 126 may configure aprotocol for communication with the identity database. In someimplementations, the protocol may be determined by an authenticationpolicy governing data access rights by participant entity 204 at theidentity database. The authentication policy may be administered by APS128 of the integrated identity management system, as disclosed herein.Each participant entity may purchase a subscription plan to theintegrated identity management system. The subscription plan may coveran authentication policy. In some implementations, AVE 126 may configurethe protocol for communication according to the authentication policy aspurchased by the participant entity. The authentication policy may covercommunication between the AVE 126 and a particular identity database.The detailed protocols may include a encryption component as well as adecryption component. AVE 126 may configure a first protocol componentfor encrypting data being transmitted from the AVE 126 to the particularidentity database. Concurrently, AVE 126 may configure a second protocolcomponent for decrypting data being received by the AVE 126 from theparticular identity database. AVE 126 may further maintain parameters ofthe identity database by: configuring component fields of identity dataof users admitted into the identity database through a vetting process.Additionally AVE 126 may manage, based on the protocol, attributescorresponding to the component fields of the identity data.Subsequently, AVE 126 may configure, in accordance to the protocol,access to the component fields of the identity data stored at theidentity database. Furthermore, AVE 126 may configure the protocol forcommunication with an identity database provided by a government entity.As noted herein, the government entity may administer a vetting processto perform background check of the user before the correspondingidentity data of the user is entered into the identity database. AVE 126may additionally configure the protocol for communication with anidentity database provided by a third party entity, different from agovernment entity and the participant entity. As disclosed herein,identity database maintained by third party entities may serve as asurrogate identity database. To the extent that identity data in suchthird party identity database may not be as reliable as identity data intraditionally authoritative identity databases, identity data in suchthird party identity databases may be treated with additional scrutiny.Examples of such third party identity database may include databasesmaintained by social media enterprises, such as, for example, Linked-inor Facebook.

Turning to FIG. 2D, an example APS 128 according to some implementationsis being shown. As illustrated, APS 128 may receive, from a transactionauthentication engine 112, an inquiry regarding a participant entity 204attempting to verify an identity of a user 202 (258). As disclosed herein, user 202 may be submitting a transaction request at the participantentity 204.

Based on the received inquiry, APS 128 may gather informationidentifying the participant entity 204 (260). The informationidentifying the participant entity may be embedded in the inquiryreceived. In some implementations, the information identifying theparticipant entity may be obtained from the transaction request beingascertained for the trustworthiness. TAE 122 may indicate theidentifying information to APS 128 with no need for retrieval orextraction.

Based on the information identifying, APS 128 may determine anauthentication policy for the participant entity to verify the identityof the user. This authentication policy may apply to all users who maysubmit transaction request at participant entity 204. In other words,this authentication policy may be a systematic policy for a particularparticipant entity and may not vary with regard to the identity of eachindividual user who may interact with particular participant entity.

Based on the determined authentication policy, APS 128 may compute avalidity score for the participant entity 204 to verify the identity ofthe user 202. As discussed herein, the validity score may depend on avalid subscription status. For example, participant entity 204 may needa current subscription to the integrated identity managements system inorder to receive a passing validity score.

Additionally, the subscription may be qualified in terms of the mannerin which participant entity 204 may access the integrated identitymanagement system, the components thereof, identity databases incommunication to the integrated identity management system, or, asdiscussed herein, similar or sibling identity management system incommunication thereto. As an illustration, the authentication policy mayprovide an access plan for participant entity 204 to use, for example,transaction authentication engine 122 of the integrated identitymanagement system. The access plan may provide, for example, a timequota, a bandwidth quota, or a throughput quota for participant entity204 to submit requests to validate to the transaction authenticationengine 122. In accordance with provisions of the subscription plan, thetime quota, the bandwidth quota, or the throughput quota for theparticipant 204 may vary as a function of when the requests to validateare being submitted (e.g., peak time or off-peak time), where therequests to validate are being submitted (e.g., more proximal or moredistal to the transaction authentication engine), etc.

Moreover, the available subscription plans may depend on the nature ofthe business conducted by participant entity 204. As an illustration,insurance companies may never obtain records of certain medical testsfor any individual patient. For example, legislative directives in manyjurisdictions may not allow insurance companies to access results ofgenetic tests. Likewise, federal HIPPA (The Health Insurance Portabilityand Accountability Act of 1996) regulations may prohibit healthcareproviders from disclosing medical information of individual patients,especially when the medical information may be sensitive.

Furthermore, subscription plans may prescribe the extent to whichidentity information may be accessible during a verification activity.As an illustration, some subscription plans may reveal only the lastfour digitals of the social security number for verification purposeswithin transaction authentication engine 122. Likewise, somesubscriptions plans may only disclose the street number or zip code ofwhere user 202 resides, without revealing the entire residentialaddress.

The validity score may be computed in accordance with the subscriptionstatus of entity 204. APS 128 may then provide the computed validityscore to TAE 122 for TAE 122 to determine a trustworthiness of thetransaction request submitted by the user at the participant entity. Asdiscussed herein, in determining the trustworthiness of the transactionrequest, TAE 122 may factor in other considerations, such as, forexample, authenticity scores attesting to the purported identity of theuser or query results from identity databases.

Notably, APS 128 may log verification activities requested by theparticipant entity 204 based on the received inquiry (264). Logging maybe a book-keeping activity to keep a record, which may be used for avariety of purposes, such as, for example, auditing. APS 128 may thenanalyze the logged verification activities to determine a usage by theparticipant entity. The verification activities may refer to anyactivity taking place anywhere in the integrated identity managementsystem or any identity database in connection with the integratedidentity system. As an illustration, APS 128 may log queries to accessan identity database as part of the verification activities requested bythe participant entity 204. As noted herein, the queries may besubmitted by AVE 126 to a particular identity database. The queries maybe submitted to verify or obtain identity data. APS 128 may analyze thelogged queries to determine the usage of the identity database by theparticipant entity. In some implementations, APS 128 may further profilethe logged queries to determine a pattern of usage of the identitydatabase by the participant entity.

Based on the determined usage of, for example, the identity database,APS 128 may perform accounting to determine a use fee to be charged tothe participant entity for accessing the identity database. In someimplementations, APS 128 may perform accounting by measuring in terms ofthe number of queries submitted to the identity database on behalf ofthe participant entity. The accounting may also be measured in terms ofthe number of responses sent to the participant entity in response tocorresponding queries. In some implementations, the accounting may beperformed to measure the data amount transmitted or received. Forexample, the accounting may measure an amount of data sent by AVE 126 toquery the identity database on behalf of participant entity 204.Similar, the accounting may also be measured by the amount of datareceived at AVE 126 on behalf of participant entity 204 from theparticular identity database. Based on the determined usage, APS 128 mayprovide feedback information to enable load balancing for any componentof the integrated identity managements system or a particular identitydatabase in communication with the identity management system. Forexample, the load balancing may be applied on AVE 126 when submittingfuture queries to the particular identity database.

When computing the validity score, APS 128 may compare the determinedusage of, for example, the identity database by the participant entitywith the authentication policy of the participant entity.Inconsistencies between the determined usage and provisions of theauthentication policy may cause a reduction of the validity score.Additionally, APS 128 may provide an administrative interface to reportthe determined usage to a human administrator. The reported usage mayprovide feedback information to elucidate the reasons behind a validityscore.

Interestingly, APS 128 may also provide an application program interfacethrough which APS 128 may extend service for the participant entity 204to access other identity databases different from the particularidentity database. More specifically, the application program interfacemay allow APS 128 to communicate with other authentication policyengines different from APS 128 to access the identity database servicedby those authentication policy engines. Conversely, the applicationprogram interface may also allow the other authentication policy enginesto access the particular identity database, access to which is beinglogged by APS 128.

APS 128 may administer an access right that is systematic for aparticular participant entity to submit inquires about the identity ofusers. The users may be requesting transactions to access data managedby the participant entity. A concern may arise about self-initiatedqueries by a participant entity. In particular, the participant entitiesmay engage in spoofing activities to query the identity information ofusers who may not be requesting a transaction with the participantentity in the first place. Such spoofing activities may lead tounwarranted accesses to identity databases. In certain cases, repeatedpolling of an identity database at a credit agency may negatively impacta user's credit score. In other cases, intensive and indiscriminatepolling of a particular identity database may lead to slower responsesfrom the identity database for genuine queries. In other words,unwarranted accesses to the identity database could amount to a denialof service attack for legitimate queries to verify user identities.Generally speaking, the concern of unwarranted access to identitydatabase may be a privacy concern. Each user may have an arguablyreasonable expectation of privacy of his or her identity data as storedin an identity database at the DMV. To address the privacy concern, avalidated individual engine (VIE) may be introduced to administer anaccess right that is specific for a particular participant entity tosubmit queries to verify a particular user's identity. In other words,the VIE may implement an access right control at an individual level,rather than a systematic control (as administered by APS 128).

A user may submit a transaction request at a relying party. The relyingparty may include, for example, a financial institution, a healthcareprovider, an insurance carrier, a merchant. In the context of relyingparty serving the user's transaction request, the user may also be knownas the requesting party. The transaction request may include, forexample, a request to access an account managed by the relying party. Insome instances, the account may include a financial account and theaccess may include monetary withdrawal. The transaction request may alsoinclude, for example, a request to download media contents from astorage facility managed by the relying party. In some instances, thetransaction request may be accompanied with credential information ofthe user, such as, for example, a password, a personal identificationnumber (PIN), an encryption key, or a digital certificate of the user.

The relying party may rely on the identity resources within a federatedsystem of transaction authentication and verification. Generally, arelying party may include a participant entity who has, for example,subscribed to a service of a federated system including the transactionauthentication engine 122, the authentication policy engine 128, and theauthentication verification engine 126. In other words, the relyingparty may rely on the providing party within the federated system. Byway of illustration, when the verification request from the relyingparty is received by the providing party, the providing party (e.g.,owner/keeper of the identity information) checks login/transactioncredentials against a database in order to determine access eligibilityand then returns results of the verification request to the relyingparty. Within the above context, the providing party may be the mostattractive location for launching on-line attacks, and thus can be themost likely root cause of identity thefts.

Implementations of perishable symbology may enhance confidence that (i)a user submitting a transaction request is the person he or she claimsto be, and (ii) the user is authorized to engage in the requestedtransaction at the time of submission. FIG. 3A is a diagram showing anexample process flow for using perishable symbology to foil, forexample, replay attacks or spoofing attempts.

In some implementations, to determine the trustworthiness of thesubmitted transaction request, the relying party may submit averification request to transaction authentication engine 122 (301).This request is for the relying party to tap into the resources of afederated system so that database information from discrete identitydatabases can be leveraged. In the context of on-line authentication ina distributed network environment, a common theme of attack includesreplay attacks, or spoofing attacks, in which the attacker attempts toreuse a captured message between the parties in later communicationswith the attacker assuming a forged identity.

FIG. 3 is a diagram showing an example integrated identity managementsystem with perishable symbology capabilities. Similar to the depictionin FIG. 1, data request 102 may represent a transaction requestsubmitted by a consumer user. The consumer may submit a variety oftransaction requests for financial, business, enterprise, or socialtransactions. The transaction authentication engine 122 may conduct adue diligence verification to determine the trustworthiness of thesubmitted transaction request. To conduct the due diligence verificationof a received transaction request, the relying party may submitinquiries to the disclosed identity management system. Inquiries may besubmitted, via respective interfaces, to transaction authenticationengine (TAE) 122. A due diligence verification inquiry concerning thetransaction request may be transmitted to transaction engine 122 (301).As disclosed herein, the verification may be processed in acontext-dependent manner according discrimination methods 104.Furthermore, such processing may follow access methods 106 that includeprotocols for verification in a given context. When the verificationinquiry is received at transaction authentication engine 122, the duediligence verification may particularly include verifying whether thetransaction request itself is not a replay attack, as disclosed infurther detail below.

In some implementations, data characterizing the transaction requestedmay be generated at transaction authentication engine. The datacharacterizing the transaction may be unique to the transaction request.Such characterizing data may include, for example, identity of therequesting party, network and geographical origination of this party;identity of the providing party, network and geographical origination ofthis party; tokenization data from the participating parties includingthe requesting party and the providing party; type of transaction;amount of transaction; time of transaction origination; permitted timewindow for communication requests acknowledgement; timestamp of the dataaccess; the actual payload data and accompanying metadata of payload;network carrier identity and routers/repeaters (and their locations)that handle the transaction information; and communication and securityprotocols used to enable the communication. The time stamp can be aunified time stamp within the federated system. In some implementations,the time stamp may originate from a network time server within thefederated system running a network time protocol (NTP). By incorporatingone or more of these associated characteristics, the chances of thecharacterizing data of two underlying transactions to be the same aregreatly reduced. In some instances, the characterizing data can besmaller or substantially smaller in size than the transaction request orthe underlying transaction. For example, the characterizing data for atransaction request to download a large media file would be a fractionof the size of the media content. In one instance, the characterizingdata may be known as the pre-transactional characteristics. In thiscontext, the characterizing data may also be referred to as metadata.The metadata can support the authenticity of the transaction request.The different types of data that could be captured to support thetransaction would merely have to be unique. Each data element, on itsown, would not be considered “individually identifiable”, butaltogether, might provide better definition of its authenticity

The characterizing data is devoid of source assets of the transaction.Source assets of a transaction, within this disclosure, generally referto the information used for identifying a user, such as the credentialinformation manifested by a password, a PIN, a security word, a digitalcertificate, or an encryption key.

In one instance, the characterizing data is generated in the form ofmachine-readable data, for example, symbology data. Example symbologymay include, a QR code, a 1-D bar code, or a 2-D bar code. In thisinstance, the symbology data may be pushed to a transaction databaseengine 310 (302). Once stored at transaction database engine 310, thissymbology data may be retrieved on a limited time basis to effectivelyfoil spoofing or replay attacks. In one instance, the symbology data maybe retrievable only once for verification and once retrieved, thesymbology data may no longer be accessible to a relying party. Inanother instance, the symbology data may be retrievable within atime-window and retrieval requests outside the time-window may not behonored. For example, if a retrieval request is received outside thetime-window, transaction database 310 may ignore the retrieval request.In some instances, transaction data base 310 may drop or punt theretrieval request. In other instances, transaction database 310 mayrespond with a message that the record is not available.

Transaction database 310 is accessible for retrieval by transactionauthentication engine 122 and authentication verification engine 126. Insome instances, transaction database 310 can be collocated withauthentication policy engine 128. In other instances, transactiondatabase 310 may be at a location separate from authentication policyengine 128.

In some implementations, transaction authentication engine 122 may waitfor confirmation that the characterizing data has been received bytransaction database 310 and saved to the database for subsequentaccess. This wait may be part of a mechanism to synchronize the receiptof the characterizing data (as pre-transactional characteristics) attransaction database 310 with subsequent transmission of data fromtransaction authentication engine 122. In this mechanism, a time-outwait can be implemented so that transaction authentication engine 122will not wait indefinitely for the confirmation that the characterizingdata has been received. In one example, authentication engine 122 mayretransmit the characterizing data to transaction database 310 when noconfirmation is received at authentication engine 122 after the time-outperiod has elapsed. In some instances, the retransmitted characterizingdata may be different from the earlier transmitted characterizing databecause, for example, the time that the characterizing data is generatedhas been updated. Noteworthy is that some implementations mayincorporate time stamps encoding both the time the verification requesthas arrived and the time the characteristics (e.g., pre-transactional)are summarized. In fact, the configuration of what time stamps to keepcan be maintained by software programming and the configuration canaffect a “formula” defining perishability. The time-out andretransmission in these instances are implemented at the applicationlevel and are supplementary to existing TCP/IP retransmissionmechanisms.

Thereafter, transaction authentication engine 122 may submit an inquiryto authentication verification engine 126 to authenticate that the usersubmitting transaction request is who he or she claims to be and toverify that transaction requested is permissible between the requestingparty and the providing party (303). The inquiry may include thecredential information of the requesting party as well as thecharacterizing data (including the summarized transactionalcharacteristics). The characterizing data is applicable only once to theunderlying transaction request.

While verifying that the user submitting transaction request is who heor she claims to be, the authentication verification engine 126 may relyon identity data 112 as stored in database of trusted sources 110 (305).Authentication verification engine (AVE) 126 may rely on access policies108 to determine whether the requesting party or the providing party mayquery an identity database. Access policies 108 may include macroscopicand microscopic policies for participant entities to query a particularidentity database.

While verifying the identity of the requesting party by queryingidentity databases 110 according to access policies 108, AVE 126 maygenerally verify the credential information submitted in the firstinquiry from TAE 122. In some instances, verifying the credentialinformation includes verifying a password, a PIN, a security word, or anencryption. The requesting party (for example, the user submitting thetransaction request at the relying party) can prove his or her identityby presenting the credential information that can be verifiedsuccessfully.

Meanwhile, authentication verification engine 126 may verify that thetransaction request from the requesting party is a freshly submittedrequest and not a replay. To this end, authentication verificationengine 126 may query transaction database 310, per arrow 304, tocorrelate the inquiry received at the verification engine 126 withcharacterizing data stored at transaction database 310. In one instance,the inquiry submitted from transaction authentication engine 122includes the characterizing data. In this instance, the characterizingdata stored on transaction database can be machine-readable data, forexample, in the form of symbology data. In another instance, thecharacterizing data included in the inquiry submitted from transactionauthentication engine 122 may also be in the form of symbology data.Retrieval of the characterizing data from transaction database 310 cansucceed before expiration (and hence the characterizing data isperishable). In some examples, retrieval query is allowed only once.This one-time use example can render replay or spoofing attacks moot asthe characterizing data is single-use only. In other examples, retrievalquery may only be allowed within a time window to enforce freshness ofthe characterizing data. As disclosed below, such characterizing datamay be compared to determine the liveness of a transaction request. Thecharacterizing data may also be used to log the transaction requests forforensic analysis.

Successful correlation within the time limit can confirm the summarizedcharacteristics of the transaction, thereby validating the transactionrequest as freshly submitted and not a replay of an earlier submittedtransaction request. A transaction request submitted as a replay willhave, for example, a different time stamp at the transactionauthentication engine 122. The different time stamp would lead todifferent characterizing data. The machine-readable data generated andstored per the earlier transaction request would not match thecharacteristics of the replayed request. If, however, a replay islaunched on arrow 302 to insert characterizing data from an earliertransaction request, this characterizing data would not match thesummarized characteristics of later transactions and therefore would notconfirm the legitimacy of later submitted transaction requests.

In a related note, the TAE (relying party side) and the AVE (trustedsource) side communicate and authorize the transaction. However the APSgoverns that “route request”. If the APS is programmed to not permitre-use of a particular transaction authorization, then a reuse attemptdoes not get routed. This feature is part of the utilitarian value ofperishable symbology to deter spoofing or replay attempts. Perishablesymbology provides a manner by which each transaction is unique andsegregated by the “time” of the request. A hacker would need toreplicate the timestamp of a transaction, and that fraudulenttransaction request would have to have the identical timestamp on allcomponents of the transaction validation and verification system throughthe request workflow, which would be very difficult and virtuallyimpossible.

In some instances, the characterizing data stored as machine-readabledata on transaction database 310 may be used to log transaction requestsreceived at transaction authentication engine (TAE) 122. The loggedentries may be encrypted to further enhance data protection. Theselogged entries may enable data analytics, for example, to study consumerbehavior on an aggregated level in response to external advertisingcampaigns. These logged entries may also enable data analytics to trackconsumer behavior on an individual basis without compromising thecredential information of the individual consumer (also known as thesource assets of each transaction). The statistical analysis on theaggregate level and at the individual level may record number oftransaction requests, type of transaction requests, distribution of thelogged transaction request per month, per type, etc. In time of a breachat transaction authentication engine (TAE) 122, the logged transactionrequest in the form of machine readable data stored on transactiondatabase 310 may be used to reconstruct the transaction request receivedat (TAE) 122 as well as the sequence in which the transaction requestswere received. Such reconstructed sequence of transactions requestreceived may assist in tracing the transpired events that led to thebreach. In some instances, the machine-readable data may includecharacteristics such as submission time of the transaction requests.

In one example, the correlation with characterizing data stored ontransaction database 310 may be performed before the verification withidentity database 110. In other words, when the characteristics of thetransaction may be confirmed first, before the access eligibility can bedetermined. In this example, a breach at the authentication verificationengine 126 may not expose the identity database 110. This is because thebreach would be revealed based on the comparison pre-transactionalcharacteristics and the verification with identity database 110 wouldnot even proceed. Stated in another way, the TAE and the AVE aregathering “environmental” characteristics of an actual transaction,which then get stored in the Transactional database. An algorithm usesthese characteristics to build a “perishable” or “temporary” markrepresenting that particular and specific actual transaction. If ahacking party tries to use past characteristics to spoof theauthenticity, the time-stamp element of the unique perishable mark,flags the replay as possibly fraudulent, and does not let the recyclingproceed. Furthermore, a breach at the transaction authentication engine122 alone may lead to a more rapid forensic reconstruction of theinfarction. This is because the breach would be detected earlier onbased on the comparison of pre-transactional characteristics. In anotherexample, the verification with identity database 110 may be performedbefore the confirmation with characterizing data stored on transactiondatabase 310.

In the context of the transaction database in FIG. 4 and “perishablesymbology,” there is the need to store the computed transactionalresults of the transaction and presents the stored transactional resultsas a unique string for purposes of access or forensic audit. The policyserver determination results can be used as part of the computation ofthis unique string/hash to characterize the transactional results. Asenvisioned in the context of perishable symbology, the database is notan “identity engine,” like the TAE or AVE, but rather a data warehouseto store characteristics, which can incorporate symbology data.

If the verifications from transaction database 310 and identity database110 are both satisfactory according to the access policies that governthe type of transaction between the requesting party and the relyingparty, authentication verification engine 126 may signal transactionauthentication engine 122 to proceed with the requested transaction(306). Otherwise, authentication verification engine 126 may signaltransaction authentication engine 122 not to proceed with the requestedtransaction. In some instances, if the verifications from either thetransaction database 310 or the identity database 110 is unsatisfactory,authentication verification engine 126 may choose not to send any signalto transaction authentication engine 122. In these instances, after atime-out period, transaction authentication engine 126 may retransmitinquires or may treat the verifications as unsuccessful.

Thereafter, transaction authentication engine 126 may signal, over arrow307, the relying party to proceed with the requested transaction if theverifications succeeded. Otherwise, transaction authentication engine126 may signal, over arrow 307, the relying party not to proceed withthe requested transaction. In some instances, if the verifications didnot succeed, the transaction authentication engine 126 may choose not torespond further to the relying party.

FIG. 4 is a diagram showing another example integrated identitymanagement system with perishable symbology capabilities. In thisexample, the authentication policy server 126 may play a larger role inthe federated system by first pre-clearing the relying party and theproviding party, and then perform transactional disposition according topre-defined risk profiles.

As discussed above, after a relying party receives a transaction request(e.g., from a consumer), the relying party may submit a verificationinquiry to transaction authentication engine 122 (301). Before thetransaction authentication engine (TAE) 122 generates thepre-transactional characteristics summarizing the transaction request,TAE 122 may first inquire at authentication policy server (APS) 126 toconfirm any business relationship between the relying party and theproviding parties (such as TAE 122) offering the verification service(401). In particular, relying parties, as users of the federatedeco-system, may first subscribe to the ecosystem, and declare whichproviding parties they have a relationship with, the nature of therelationship (e.g., the type of identity data being sought). In someinstances, this information is stored in a business rules (biz rules)repository, for example, associated with access policies 108. In otherinstances, technical information is also declared (e.g. mutually agreedupon communication and authentication protocols, and allowable contactwindows) and stored in a workflow database, for example, associated withaccess methods 106. As illustrated in FIG. 4, APS 128 may then confirmeach relationship and the terms stored in the business rules repository(402B). The technical information including protocols can be similarlyverified (402A). When the business rules and work flow information areacceptable and reconciled, APS 128 may place the relying party on the“cleared” list (e.g. a whitelist) of the providing party (such as TAE122). When a relying party is on the providing party's whitelist,additional verification inquiries from the relying party may beprocessed automatically and without additional confirmation of thebusiness rules and work flow protocols by APS 128. On the other hand, ifelements of business rules or work flow information cannot be verified,or is otherwise problematic, then the relying party may be placed in a“review” status, for further disposition. This means “automatic”processing of verification inquiries may be inhibited and additionalverification inquiries from the relying party may still be processed byAPS 128 confirming the business rules and work flow protocols. When thebusiness rules and specified work-flow protocols are satisfied, then thetransaction request may be processed further within the federatedsystem.

Subsequently, transaction authentication engine (TAE) 122 may pushpre-transactional characteristics to transaction database 310 (302). Asdiscussed above, the pre-transactional characteristics may be in theform of perishable symbology data. Thereafter, transactionauthentication engine 122 may submit a inquiry to authenticationverification engine 126 to authenticate that the user submittingtransaction request is who he or she claims to be and to verify thattransaction requested is permissible between the requesting party andthe providing party (303). Here, APS 128 may play a similar role.Authentication verification engine (AVE) 126 can confirm any businessrelationship between the relying party and the providing parties (suchas AVE 128) offering the verification service (403). As illustrated inFIG. 4, APS 128 may then confirm each relationship and the terms storedin the business rules repository (404B). The technical informationincluding protocols can be similarly verified (404A). When the businessrules and work flow information are acceptable and reconciled, APS 128may place the relying party on the “cleared” list (e.g. a whitelist) ofthe providing party (such as TAE 122). When a relying party is on thewhitelist of AVE 126, additional verification inquiries from the relyingparty may be processed automatically and without additional confirmationof the business rules and work flow protocols by APS 128. On the otherhand, if elements of business rules or work flow information cannot notbe verified, or is otherwise problematic, then the relying party may beplaced in a “review” status, which means “automatic” processing ofverification inquiries may be inhibited and additional verificationinquiries from the relying party may still be processed by APS 128confirming the business rules and work flow protocols. When the businessrules and specified work-flow protocols are satisfied, then thetransaction request may be processed further within the federated system(304-307).

In the above illustration, tiers of access rights may be created, basedon different subscription classifications. Such tiered access rights maythen be updated in the business rules repository database. For example,in addition to the breach protection discussed earlier, othersituational protections, such a “spoof” and “clock override”protections, can be added by configuring the APS 128 to authenticate thetransaction requests against the pre-defined times, methods and rules.

In the illustration, APS 128, though shown as a single instance proxy,may be configured as a federated set of servers or virtual machines,synchronized and dedicated to the functional protection of requestcompliance checking.

FIG. 5 is a diagram showing another example integrated identitymanagement system according to some implementations. In the exampleshown, VIE 502 may be implemented at a level corresponding to theworkflow layer 106. As disclosed herein, workflow layer 106 may beinterchangeably referred to as the access methods layer 106. VIE 502 maymaintain a database including access control data for each user. In someimplementations, the access control data may include a list ofauthorized business partner permitted by an individual user to queryidentity database(s) to verify the individual user's identity. Asdisclosed herein, the individual user may operate in the capacity of anaverage consumer who may request transaction with a provider. Theprovider may be providing goods, service, land access, etc. The providermay also be known as a participant entity of the integrated identitymanagement system as disclosed herein. The access control data may beupdated by the individual user to include newly authorized businesspartners or remove existing authorized business partners. The list ofauthorized business partners may operate like a reverse nationaldo-not-call list, as mandated by the Federal Trade Commission (FTC) tocurb unscrupulous telemarketing. Here, a participant entity may onlyverify the identity of a user if the participant entity is on the listof authorized business partners.

FIG. 6A shows another example workflow for determining a trustworthinessof a transaction request submitted by a user at a participant entityaccording to some implementations. User 202 may register participantentity 204 at VIE 502 as an authorized business partner of user 202 inthe integrated identity management system (601). VIE 502 may providefeedback to user 202 indicating status change (602). In someimplementations, VIE 502 may detect an unauthorized participant entityattempting to verify an identity of user 202. VIE 502 may promptly blockthe attempted verification by, for example, instructing TAE 122 to dropthe verification request. VIE 502 may then notify user 202 of theunsuccessful intrusion. In one configuration, the report may begenerated on a per incident basis. In another configuration, the reportmay be generated per time period, for example, weekly, monthly, etc.

Once participant entity 204 has been registered as an authorizedbusiness partner of user 202, participant 204 may request the integratedidentity management system to validate a transaction request submittedby user 202 at participant entity in a manner consistent withdiscussions above, for example, in association with FIG. 2A. Work flowillustrated by arrows 604-612 are similar to work flow illustrated byarrows 221 to 229.

The following provides an example workflow of signing a mortgagerefinance document to highlight nuances that may be introduced by addingVIE 502 to the integrated identity management system. Initially, amortgage institution, such as a bank, may send a web-link to anindividual consumer. The web-link points to a secure web-site for theconsumer (a homeowner) to review the refinance paperwork electronically.In this example, the mortgage institution may operate in the capacity ofparticipant entity 204 with the consumer in the capacity of user 202.

Upon receipt of the web-link, the homeowner may follow the web-link tothe secure web-site using credential information based on, for example,the recipient email address. The homeowner may complete the applicationpaperwork and may then prepare to sign. The homeowner may utilize VIE502 to assist in the signing process. For example, the homeowner mayhave an account at VIE 502. In logging into the homeowner's VIE account,the home owner may present credential information. VIE 502 may run alocal query to verify the presented credential information. If the userauthentication is unsuccessful, the home owner's attempt to use VIE 502may be aborted. If the user authentication is successful, VIE 502 mayproceed to provide identity functionalities for the homeowner to signoff the mortgage refinance application. For example, VIE 502 may sendthe transaction request of the refinance application to the bank. Therefinance application is now waiting for an e-signature of thehomeowner. The transaction request may be processed by TAE 122 incommunication with the bank. TAE 122 may consult APS 128 to determine,for example, the subscription status of the bank to use the integratedidentity management system or to query an authoritative identitydatabase. As discussed herein, APS 128 may administer the systematicright of access for a participant entity, such as the bank, to inquireabout the authenticity of user identities through the integratedidentity management system. If the bank has adequate subscription statusto verify identities of users, then APS 128 may allow TAE 122 to proceedfurther. TAE 122 may then engage in a dialog with VIE 502. If thetransaction request is originated by user 202, for example, if the usersubmitted the transaction request sua sponte and without directives fromparticipant entity 204, VIE 502 may register the participant entity 204as an authorized business partner of user 202. In this particularexample, the bank initiated the work flow and hence the transactionrequest, in the form of the refinance application, may not be deemed tobe originated by the homeowner. Instead, in this example, the refinanceapplication was solicited by the bank. In a situation in which thetransaction request is not originated by user 202 (for example,solicited by participant entity 204 or even faked by participant entity204 in a spoofing effort), then VIE 502 may check the list of authorizedbusiness partners to determine whether participant 204 is authorized touse the integrated identity management system to query an identityinformation for user 202.

As discussed herein, such access control is on an individual level andspecific to each user 202, as compared to a systematic control of accessright by APS 128. VIE 502 may return a numerical score indicating thelevel of authorization possessed by a participant entity with regard toa specific user, or even the level of authorization possessed by theparticipant entity with regard to a specific transaction request fromthe specific user. For example, corporations may have a hierarchicalstructure. After merger and acquisition activities, company A may becomea subsidiary of company B. If company A was an authorized businesspartner of user 202 and company B was not, the power of company A may becarried upward to company B per the merger and acquisition agreements.Conversely, if company B was an authorized business partner of user 202and company A was not, the power may be carried downward to company Aper the merger and acquisition agreements. In cases where merger andacquisition is a result of bankruptcy proceedings, the merger andacquisition agreements may provide more qualified carry-over of theauthorization power. A numerical score may quantify the extent of powercarry-over in a hierarchical structure that is context specific. Inother examples, the numerical score may also indicate the attenuation ofthe authorized power if user 202 provides negative reviews with regardto services or goods received from an authorized business partner ofuser 202. If the negative reviews reached a threshold level (forexample, the number of negative reviews or the amount negativityposted), the particular authorized business partner may be automaticallyremoved from the list of authorized business partners. Conversely, thereduced power may be cured if user 202 posts positive reviews regardingmore recent transactions with the authorized business partner.

Additionally, VIE 502 may provide a user interface to allow user 202 toregister a chosen participant entity as an authorized business partner.The user interface may also allow user 202 to remove a currentauthorized business partner from the list. In a way, the list ofauthorized users may function as a reverse do-not-call list, as mandatedby the FTC to curb unsolicited telemarketing calls.

Notably, however, the user interface as disclosed herein may allow auser to assert more fine-grained access control. For example, the usermay authorize finance institutions to verify the user's identity with aprescribed set of identity databases. In other words, the authorizedidentity database for a finance institution (e.g., an insurance company)may include identity databases administered by a DMV, but may notinclude identity databases administered by hospitals. Moreover, the usermay authorize a particular business partner to access identity data inprescribed format. For example, the user may, by default, authorize theparticular business partner to obtain residential address only at thegranularity of zip code, or at the granularity of city and state,without the street address or house number. Furthermore, the user mayprescribe the type of queries that might be submitted at a particularidentity database in order for an authorized business partner to verifythe user's identity. For example, the user may limit insurance companiesto be query only about identity records at hospitals in the past threeyears. Similarly, the user may limit insurance companies to receiveresponses from identity databases administered by a hospital. Forexample, the received responses may be limited to identity data duringthe past three years, etc. Hence, the user interface may enable avariety of individualized access control over the manner in which theparticular user's identity data may accessed by authorized businesspartners.

FIG. 6B shows an example flow chart performed by VIE 502 according tosome implementations. VIE 502 may receive a request to verify anauthorization status in association with a transaction request (614). Asdisclosed herein, the transaction request may include a variety ofactivities and may not be limited to financial or monetary transactionsonly. The transaction request may be submitted by a user attempting toaccess data managed by a participating entity. The participant entitymay employ the integrated identity management system as discussed hereinto verify an identity of the user before proceeding with the requestedtransaction. In the context of verifying the user's identity, theauthorization status may be indicative of a power of the participantentity to verify, on the integrated identity management system, theidentity of the user.

Based on the request to verify, VIE 502 may determine the identity ofthe user submitting the transaction request (616). VIE 502 may alsodetermine the identity of the participant entity (618). The identitiesof the user and the participant entity may be determined in parallel orin serial.

Based on the determined identities of the user and the participantentity, VIE 502 may query a database at VIE 502 (620). As discussedherein, the database administered at VIE 502 may include a list ofauthorized business partners for the particular user. An authorizedbusiness partner is a participant entity that is permitted by the userto query identity data associated with the user. The database may alsoinclude more fine-grained access control over the manner in which suchidentity data may be accessed by a particular authorized businessparent.

According to results from the querying, VIE 502 may determine theauthorization status (622). As discussed herein, the authorizationstatus may be determined as a numerical score to indicate the relativepower possessed by the participant entity to verify the user's identity.The determined authorization status may be communicated (624) to theparticipant entity, the transaction authentication engine engaged by theparticipant entity, etc.

In some implementations, VIE 502 may query the database at the verifiedidentity engine to determine whether the participant entity, as anauthorized business partner of the user, is authorized to engage in therequested transaction between the user and the participant entity. Inresponse to determining that the participant entity, as an authorizedbusiness partner of the user, is authorized to engage in the requestedtransaction between the user and the participant entity, signaling theparticipant entity to proceed with the requested transaction. Inresponse to determining that the participant entity, as an authorizedbusiness partner of the user, is not authorized to engage in therequested transaction between the user and the participant entity,altering the user and the participant entity that the participant entityis not authorized to engage in the requested transaction.

In some other implementations, if the transaction request was originallysubmitted by the user to the participant entity and that participantentity is not yet an authorized business partner of the user, VIE 502may treat the submission as an implied authorization for the participantentity to verify the user's identity. In response, VIE 502 may register,in the database, the participating entity as an authorized businesspartner of the user. If the transaction request being submitted by theuser was solicited by the participant entity, VIE 502 may query thedatabase to determine whether the participant entity is an authorizedbusiness partner of the user. If the participant entity is not yet anauthorized business partner of the user, VIE 502 may alert the user thatthe participant entity is not an authorized business partner. In oneconfiguration, VIE 502 may further alert a transaction authenticationengine engaged by the participant entity to hold off further processingof the request submitted by the participant entity to verify identity ofthe user. Similarly, if the participant entity is not yet an authorizedbusiness partner of the user, alerting the user that the participantentity is not an authorized business partner; and alerting the entitysubmitting the request to verify to hold off processing a particularrequest from the participant entity with regard to the user.

In still some other implementations, VIE 502 may provide a userinterface to allow the user to register a specific participating entityas an authorized business partner. The user interface may allow the userto configure one or more types of transactions as permissibletransactions between the user and the authorized business partner. Theuser interface to allow the user to configure one or more types ofpermissible queries submitted by the authorized business partner anddirected at a particular identity database.

In yet other implementations, VIE 502 may gather information capable ofidentifying the user as well as information on authorized businesspartners of the user. VIE 502 may then store, in the database at theverified identity engine, the identifying information, and informationof authorized business partners. VIE 502 may gather identity informationto attest to a purported identity of the user before granting access tothe database at the verified identity engine. Additionally, VIE 502 maygather information on permissible queries at a particular identitydatabase by each authorized business partner of the user. Furthermore,VIE 502 may also gather information on permissible data responses from aparticular identity database to each authorized business partner of theuser.

FIG. 7 shows yet another example workflow for determining atrustworthiness of a transaction request submitted by a user at aparticipant entity according to some implementations. The improvementmay include the envisioned interfaces to directory services to furtherenrich the type of identity data that may be accessed through theintegrated identity management system, as disclosed herein. In someimplementations, VIE 502 may query directory service 718 (702).Directory service 718 may then provide the query results back to VIE 702(703). Likewise, APS 128 may interface with directory service, asillustrated by arrows 711 and 713.

Directory service 718 may include active directory (AD) service. Thedirectory service may be based on, for example, Lightweight DirectoryAccess Protocol (LDAP). The directory service may generally administerand maintain distributed directory information, much like Yellow Pagesor White Pages for listing residential address or telephone of eachsubscriber of the telephone network. The directory service may likewiseprovide such consumer information as name and address (residential andemail). The directory service may similarly provide provider informationsuch as vendor name, type of business, address, web-site, etc. Thedirectory service may also provide links to consumer reviews for aparticular vendor opting into the integrated identity management system.In some implementations, the directory service 518 may be maintained andadministered by the integrated identity management system to includeinformation of participating consumers and subscribing participantentities. In some other implementations, the directory service may beadministered by an organizational entity, for example, an academicinstitution such as a university, a research institute, a hospital, etc.The organizational entity may opt in the integrated identity managementsystem through the application programming interface at, for example,the authentication policy server (APS 128). Thereafter, the employee orstudent information may be accessible by VIE 502 or APS 128. Inclusionof the directory service may further improve the amount and quality ofthe identity data accessible on the envisioned integrated identitysystem.

FIG. 8 is a diagram showing yet another example integrated identitymanagement system with perishable symbology capabilities. This exampleincludes an individual mechanism for an individual participant toself-declare his or her identity, and make an assertion to participate,or limit participation in the ecosystem. Additionally, the individualuser can limit how third-party data requestors (e.g., relying parties)can make inquiries on the individual's behalf at identity databaseswithin the federated transaction authentication and verification system.

In some implementations, an individual user may self-declare one'sidentity by utilizing a “biometric core platform”. Initially, theindividual user may create a digital abstraction to represent anidentity of the individual user. In some instances, the digitalabstraction may be created to incorporate biometrics of the individualuser as well as a series of “personal trust.” For example, biometric canbe in a digital form, such as an electronic signature, a digital fingerprint, a digital palm print, a digital iris scan, a digital retina scan,a digital facial portrait, a digital skin texture, a vice print, a gaitcharacteristic, or even a DNA digitally captured. The biometricrepresents unique personal traits of the individual user, which stilluniquely describes this individual. In one instance, the electronicproof of identity may be subject to additional encryption (for example,by the holder's private key) to further prevent tampering. In anotherinstance, a digital biometric may be embedded as digital watermark in adigital portrait of the individual user. In yet another instance, onebiometric can be embedded in another biometric to provide enhancedauthenticity. For example, a digital finger print may be embedded as awatermark in the digital portrait of the same individual. In someimplementations, the digital biometric may be self-captured by theindividual. For example, the digital portrait of the user may be takenby the user himself. By way of illustration, after the digitalabstraction is created to represent a digital identity of the user, thedigital identity may be lost or stolen and the individual may revoke thebreached digital identity. The revocation can be immediately effectivewithin the federated eco-system. Hence, lost/stolen electronic proof ofidentity can be readily recognized during verification.

The individual can then declare himself or herself to the ecosystemusing validated individual engine (VIE) 502 to configure access rightcontrol to identity databases of the federated ecosystem. In declaringhimself, the actual biometrics of the individual user may not be storedin the eco-system. Only a unique representation of an identity “mash up”from the individual may be stored.

As illustrated in FIG. 8, when the individual user presents a digitalidentity to VIE 502, VIE 502 may engage APS 128 (801) and databasesencoding access methods (802) as well as databases encoding accesspolicies (803). As noted above, VIE 502 implements access right controlat an individual level, rather than a systematic control (asadministered by APS 128). Through a predefined set of negotiations withAPS 128 and the appropriate databases, the individual user can implementaccess rights control so that providing parties may obtain commensurateaccess rights to identity data of the individual user. Transactionalelements that are definable may include, for example: parties with whomthe individual has a relationship with; primary and alternativelocations where ecosystem access is requested/performed; and transactioncharacteristics such as defined monetary limits or transaction typesthat are permitted, by certain relying parties and/or certain providingparties. In some implementations, APS 128 may consolidate the inputconfigurations from VIE 502 and stores the configurations into thecorresponding accessible databases. Subsequently, when a relying partyinitiates a verification request regarding a transaction request, APS128 will run the verification steps, not only for business to business(B2B) situations, but also for the context of individual interactions,functionally limiting or curtailing the transaction constraints asspecified.

In the examples enumerated above, no single point of failure exists. Noactual transactional data is preserved or monitored by the components ofthe eco-system, except the transaction characteristics and constraints.Actual data may only be passed between relying and providing parties.Thus, vulnerability to replay attacks may be greatly reduced andforensic reconstruction enabled by virtue of the unique transactionalcharacteristics and constraints.

Some implementations may provide methods to characterize a dispositionof individual identity based on physical credentials and biometric data.In these implementations, a portable computing device may be used. Someimplementations may be employed to vet an individual identity, and canenable that identity for enrollment and use in a data transaction whereindividual identity matters. Such enrollment and use may promotecorporate adoption and industry growth.

For context, the biometrics market is estimated to grow from $4.2billion in 2010 to $11.2 billion in 2015, at an estimated CAGR of 21.6%.The growth of the biometrics market is mainly due to increasing concernsof the countries in terms of strengthening national security. Amongstall the biometrics modalities, automated fingerprint IdentificationSystem (AFIS) market was estimated to generate the highest revenue of$1.4 billion in 2010 and is expected to reach $3.3 billion in 2015, aCAGR of 19%. Adoption of AFIS in national IDs and civil identificationis the prime reason behind the growth of AFIS market. However, the IRISvein and face market is expected to grow with at a CAGR of 19.9% from$1.4 B to $3.5B.

Despite the announcement of a biometric data standard by NationalInstitute Standard & Technology, adoption of biometrics data remainlimited. This may be attributed a myriad of legacy technical standardsproliferated from the many established biometric device companies andthe lack of local computing power. Compounding the chaos, a sea of newsoftware-based biometric algorithm and analysis companies also attemptedto seize this market opportunity. As a result, the adoption of biometricdata is low and many implementations around identity management may belimited to physical credentials—most typically a physical,government-issued ID travel papers, or a key or security token.

Some implementations may incorporate advances in biometric data captureas well as algorithm computation and storage of the data withpurpose-designed hardware. Such storage may be optimized for a specificclass of biometric data, and may require interpretation andauthentication approval performed in conjunction with server computersto run the analysis algorithms. In some instances, access to suchsystems can be limited, and typically done as a forensic or audit eventafter criminal or fraudulent activity has been performed. Such methodscan impair the broad adoption by limiting each stage of the process todedicated hardware or custom software, which is very expensive tomanufacture, procure and complicated to use.

Some implementations may enable a more secure manner to vet personalidentity to a secure portable computing devices (including but notlimited to laptop and portable computers, smartphones, tablets, wirelessmedical or health and wellness devices, GPS, or pedometer and wearablecomputing accessories, such as electronically-enhanced glasses,wristwatches and helmets. Some implementations may enable secure datatransactions into a trusted transaction ecosystem, by enhancing identityverification through incorporating the possession of a physicalcredential with multi-modal biometric authentication on a portablecomputing device. Some implementations may create a standards-neutral“platform” to simplify the capture, enrollment, comparison andinterpretation of biometric data by resorting to a general-purposeconsumer device. Some implementations can broaden adoption forbiometrically-enabled transactions by using readily available,commercial hardware device. Some implementations may provide thesoftware and methods to extend the utility of different types ofbiometric data, within the context of the general purpose portablecomputing device. Some implementations may create opportunities forintegrating other biometric and personal identity-related data methodsinto the platform, as dictated by a consumer user.

Referring to FIG. 9A, the Biometric Core Platform (BCP) 900 mayfacilitate create a secure, unique electronic identity that combines aphysical or machine-readable identity credential with the parallelcapture, processing, storage and disposition of multiple types ofbiometric data. This multi-modal biometric capability, for example, whenapplied along with a physical identity credential, can allow the user tomore confidently assert their unique identity when performing anelectronic transaction. In some implementations, the “enhanced identityprofile” may be enabled by using algorithmic methods to combine specificbiometric data with the electronic representation and validation of aphysical credential. Events or data transactions which may requireincreased security could require multiple challenge/response iterations,or additional individuals' biometric data, such as in the case ofmonetary transactions or identity inclusion into a trusted transactionecosystem. The BCP would execute and disposition this challenge/responsecycle, and contain the individual's biometric profiles—including but notlimited to: facial map, fingerprint, skin texture, iris, body scent,movement gait, dental topology, etc.

Some implementations may additionally include configurable computationalengine 910 to perform multiple functions pertaining to the capture,storage, caching, and disposition of biometric data. Engine 910 mayprovide a multi-processor system with multiple processing threadscapability. In some instances, the data management process can beparallelized to enable parallel comparisons and threshold mappings.Engine 910 may include, for example, a consumer mobile device, aportable device, or a desktop device.

Some implementations may provide a threaded computational engineconfigured to digitize and capture the demographic information of aphysical identity credential or document. The computation engine mayprocess the receipt of identity credentials and biometric enrollmentdata from third party stores and providers. Examples of identityproviders may include, for example, an IdentiGO center. In someinstances, the computation engine may encrypt and store the physicaldemographics information for use in subsequent data transaction events.The computation engine may further create and proliferate the “enhancedidentity profile” and exchanges the profile with other services to whichthe individual has an active subscription.

Some implementations may provide a multi-tenancy environment wherecomparisons and computations can be performed upon data stored inmultiple identity databases, the computational engine will prioritizeand queue the requests, cache the interim results, and present resultsof the disposition. The identity databases may include local identitydatabase 904, which may be located on device 910. Some implementationsmay provide configurable mobile databases as an aggregation point forthe biometric data captured locally. In some cases, the mobile databasemay include raw data from the biometric data capture. The mobiledatabase can also store a results hash, which obfuscates the quality andphysical accuracy of the raw data. In this manner, loss of thecommercial device, for example engine 910, may not lead to a loss ofelectronic identity. Some implementations may provide multiple mobiledatabases to provide response to type-specific data requests, or enablequery load balancing among the multiple databases. In some cases,multi-tenant databases may be accessed. In these cases, the localdatabase will retain location and access methods, in order to processthe raw data or computational request. Some implementations mayincorporate a commercially-available consumer device, with or withoutdirect integration of biometric capture devices.

The identity databases may also include externally hosted biometricdatabases 914A and 914B. Externally hosted databases 914A and 914B mayinclude, for example, a Lexis-Nexis identity database, an Equifaxidentity database, or an authoritative DMV database. As illustrated inFIG. 9A, engine 910 tap into not only local database 904 but alsoexternally hosted biometric databases 914A and 914B. Someimplementations may provide a variety of biometric algorithms 902A to902D. Each biometric algorithm may correspond to a particular biometricidentity modality, for example, facial recognition, finger print,palm-print, or iris-scan. In some implementations, a biometric algorithmmay include a biometric template for matching purposes. The biometrictemplate may be specific and unique to each subject, much like apassword or a PIN. Some implementations may include interpretationalgorithm 906 to blend verification results from querying multipleidentity databases. Particularly, implementation algorithm 906 mayinclude calculation of trustworthiness based on disposition results frommore than one identity databases. For example, an interpretationalgorithm 906 may engage a facial recognition biometric algorithm withan assurance of 80% or better, while another may engage the facialrecognition biometric algorithm with a finger print recognitionbiometric algorithm.

Some implementations may provide a communication layer. As illustratedin FIG. 9A, engine 910 may include an external interface 908 couplingengine 910, via layers 912A and 912B, to the example externally hostedbiometric databases 914A and 914B. Layers 912A and 912B may includevirtual or physical communication links customized for thetransportation of identity-related data. For example, such links may becustomized to transfer only a hash of data requests versus the actualdata. In some implementations, the BCP system can pass a uniquerepresentation, such as a hash of biometric data, in lieu of the actualphysical biometric data. Under this approach, engine 910 may queryexternally hosted databases 914A and 914B to obtain a hashed biometrictemplate to be transferred over layers 912A or 912B. Engine 910 may alsotransmit a hashed version of a captured biometric over layers 912A or912B to externally hosted databases 914A or 914B. This approach canprotect the trusted biometric data and individual identity by neverrevealing the actual biometric data, or computational methods forverifying biometric data over layers 912A and 912B. This approach mayprovide immunity to replay attacks if the hash is incorporated into atransactional characteristic being transferred over layers 912A and912B.

Some implementations may enable use of transactional data within aclosed network, when embodied as a discrete instance. Otherimplementations may be established within a virtual private network(VPN) or may have an application programming interface (API) andsufficient system access to facilitate the system connections toasset(s) within the VPN. These implementations may additionally includethe use of transactional data across general purpose IP networks such ascellular, WiFi, or wired access to the internet. In theseimplementations, communication and identity presentation can be throughcloud environments, or through hybrid server environments. Theseimplementations may also incorporate single or multi-tenancy algorithmicand computational services as well as data management at various stepsof physical data capture, data storage, computational query and identitydisposition.

FIG. 9B illustrates an example hierarchical data flow in an identitydata transaction system 920. User/device 922 may present a consumerdevice such as a smart phone, a tablet, a laptop, a kiosk, or a desktopdevice. Data I/O 924 may represent a user interface (e.g., userinterface 908). Data I/O 924 may read data from physical credential 916.The data may be obtained by, for example, scanning a machine readablecode of a physical identification document, decoding payload informationfrom the watermark on the physical identification document, readinginformation by optical character recognition, scanning biometricinformation (such as a facial portrait) from the physical identificationdocument. In some implementations, the physical credential may bepresented in the form of a digital identification on the touch screen ofa user device.

Data I/O 924 may further engage a communication channel (e.g.,communication layers 912A and 912B). In some implementations, a userselection may be made via data I/O 924 with regard to methodsdiscrimination 926. For example, a user may choose a computation method,or a threshold level for verifying an identity (digital, physical, orcombined). Methods discrimination may apply to multimodal identityverification 928. For example, the identity verification may includemultiple modalities including various biometrics (such as facialrecognition, finger print, palm print, etc.) as well as physicalidentification documents. A particular modality may have a correspondingverification template algorithm or an associated threshold level fordetermining a successful match. As illustrated, the multimodalidentification verification 928 may include determination contributionsbased on a physical credential 916.

Multimodal identity verification 928 may engage data selection 930 tochoose from the available database discrimination 934. As illustrated,the available identity databases may include a variety digital biometricdatabases, including facial portrait database 936A, skin texturedatabase 936B, iris pattern database 936C, as well as off-devicebiometric databases 938 (such as gait pattern database 938A and scentpattern database 938B). Here, the biometric data can be captured by userdevice 922.

FIG. 9C illustrates another example hierarchical data flow in anidentity data transaction system 940 that leverages identity databases942A, 942B, and 942C at various levels. System 940 includes a userinterface 956 to process and analyze identity data provided by system940. System 940 also includes an identity discrimination programminginterface to blend in identity data from third parties.

User interface 956 may engage physical credential service 958A. Anexample physical credential service may include work flow to obtaindemographic information from a physical identification document, such asa driver's license, a passport, a student ID, a member ID, or anemployee ID. The work flow through user interface 956 may include a userexperience aspect, as annotated as UX. The work flow may includeextraction methodologies to extract demographic information of theholder of the physical credential from a presented physical credential.The extraction methodologies can read encrypted information from thepresented physical credential. In some cases, such encrypted informationmay be embedded in digital watermarks on the physical credential. Insome cases, such encrypted information may be located in amachine-readable zone of the physical credential.

User interface 956 may interact with access controls service 958B. Anexample access control service 958B may refer to workflow that includespresenting challenges to an end user whose identity is being verified,and receiving responses from the end user. Access may be conditioned onmatches (or substantial matches). Statistics of number of matches,number of trials, and complexity of challenges/responses may be recordedand analyzed.

Third party processing module 948 may utilize third party softwareand/or services 944 and third party business intelligence 946. Thirdparty software and/or services 944 may include software services andprocesses from a third-party neutral with regard to a particulartransaction being conducted between a consumer user and an underlyingidentity data transaction system, such as identity data eco-system 940.Third-party business intelligence 946 may include statistics, rules, oranalytics of the third party neutral. The third-party businessintelligence 946 may be analyzed by third party software and/or services944 to generate enhanced identity profile 950. An example enhancedidentity profile 950 may incorporate the identity data from the relatedthird-party neutral according to the applicable software services andprocesses as well as the corresponding business intelligence.

As illustrated, an identity discrimination programming interface 954 mayleverage identity data from database 942A. In analyzing such identitydata, identity discrimination programming interface 954 may utilizethird-party hardware data capture methods and systems to supplementadditional identity data from third parties. In some instances, anenhanced identity profile 950 may additionally provide algorithms andthreshold levels for querying databases 942A.

Identity discrimination programming interface 954 leverage computationalalgorithms service 960A and biometric database registration service960B. Computational algorithms service 960A may provide credentialcreation (such as the generation of digital biometric information), theobfuscated data (e.g., providing hashes of digital biometric data fortransportation over a communication layer), database discrimination(e.g., selection of database(s) for a particular application). Biometricdatabase registration service 960B may interface with database 942B sothat identity data transaction system 940 may leverage identity data ondatabase 942B.

The above described components may be implemented as software layersresiding on event service layer 962. The event service layer 962 maygenerate software events corresponding to prescribed conditions (such asassurance determination reaching a threshold level) or detectedreal-world events (such as leveraging identity data from a third party).The event layer 962 is provided over programming environment 964provided for a particular underlying operating system 968.

The transaction authentication engine according to some implementationsmay electronically enable data exchanges among multiple interestedparties. Such data exchanges may allow each party to vet the identity ofthe other parties in a manner that is secure so that the vettedidentities may be “trusted.” These data exchanges may include forexample, commercial transactions as well as non-financial communications(such as healthcare records).

In 2012, 12.6M individuals were victims of identity theft—mainly fromdata breaches of sensitive account information (social security, bankaccounts, etc.), attributing to approximately 5.3M man-days spent torectify the breach. Financial fraud accounted for $21B in lossesthroughout the financial services industries, and $41.3B in losses inhealthcare due to medical identity theft.

This issue plagues, for example, financial institutions. Some may createtheir own proprietary, in-house networks and databases and businessrules schemas to handle their particular requirements, and createfinancial reserves to account for instances of fraud that may slipthrough. Such measures may protect the institution, but ignore theindividual end user who may be denied access or suffer from identitytheft. As each institution has its own requirements on quality ofidentity data, the institution is unable to share the identityverification information with other interested parties in a programmaticmanner. Relying on human intervention general becomes less feasible oreconomical when the volume of identity data increases.

Some implementations may support the creation of a trusted identityecosystem. In these implementations, software, systems and methods maybe provided to extend institutional data requirements and trust-levelsto support programmatic automation and trust-level standardizationwithin the identity ecosystem. Some implementations may handle growingidentity-related problems in the commercial markets by improving thetechnological quality and commercial viability of trusted identitieswhile simplifying the process of individual-initiated andbulk-automation steps towards mitigating crime and fraud related toidentities. Some implementations may be integrated into the eco-systemof identity data transaction. In some cases, identity-related securitytechnologies such as: Smart Card/Token based security systems,public/private software key combinations, and thick client biometricsoftware and hardware peripherals, may be integrated.

The Transaction Authentication Engine (TAE) may provide a set ofdatabase rules and computational algorithms prescribing the electronicmeans and workflow rules by which the participating entity is permittedto interact with the trusted transaction ecosystem and its “agents offunctionality.” Additionally, the TAE may define a set of intermediaryalgorithms necessary to compute the “minimum level of trustworthiness”acceptable to the participating entity in the ecosystem. For instance,the TAE may include sessions from data requestors from within a commonparticipant subscription (e.g., a company with a centralized policymanagement hierarchy, but with distributed decision-making and identityverification needs for a multitude of purposes). Each instance of arequesting event can dictate the software application, securityenvironment, communications protocol, originating domain name server(DNS) and subnet, infrastructure such as transmission controlprotocol/internet protocol (TCP/IP), one or more security protocols suchas secure sockets layer (SSL) or a virtual private network (VPN) orpublic key infrastructure (PKI), a centralized permissions/subscriptionenforcement engine, one or more centralized business rules expected forthe transaction, a minimum computed threshold of trustworthiness, asingle or a plurality of participating trusted identity Databases, acustom system configuration instance for each database, systemadministration functionality, and any required hardware or devicesrequired to perform these actions.

In an example implementation, commercial businesses, such as a bank, maydesire to verify the identity of an individual for a trustedtransaction. Here, the data requestor uses their configured applicationto initiate a data query transaction at the bank. The applicationconfigures the query based on specifications such as configurations fordataset, methods, expected response type, and security tokens. By usingsecured communications, the system may verify the subscription of thedata requestor, process the request against business rules, and send thequery to the trusted identity database. The trusted identity database inturn is configured to accept and reply to data query transactions basedon a custom configuration. The data query transactions may include, forexample, verifying that the data requestor is not on a black list, thedata requester has submitted a compliant query, and that the request isin a proper format. Once validated as a compliant transaction, the queryis performed and the database response is formatted for reply and sentback through the system, and to the data requestor.

Features of the TAE subsystem may include a scalable configurationengine. The configuration engine may function as a “local” complianceengine—initiate data requests upon the trusted transaction ecosystem(TTE), per their subscription status. The TTE may also be referred to asthe identity data transaction system, or the identity data eco-system.The configuration engine may provide mapping-defined “connectors” in amulti-tenancy environment, combining local rules and requirements withthe gaps of knowledge in order to determine programmatically whichpieces of information are missing, and which sources of data to query.The configuration engine may present (e.g., in a multi-tenancyenvironment) the defining protocols, security, and data parameters forthe bidirectional data transaction to take place, to determine whetherthe authenticity of the transaction is trustworthy. As deployed in amulti-tenancy, multi-instance solution, the configuration engine maydecentralize the business rules and data transaction elements of thedata requesting entity of the ecosystem. This decentralization mayreduce the impact of negative events such as outages, while spreadingthe computational and data burden across other TAEs deployed by thecorporate request originator. The configuration engine may also providean access “gate” by leveraging biometric (or biometrically fused data,alone), or in combination with real-time data-hashing algorithms toensure the data request is authentic (and not hacked or spoofed).

In some implementations, the TAE can be deployed on a single serverinstance or across a federation of server instances. This engine thenpasses a “hash” of the request, the communication codes, and the targetof requesting data providers. These elements may be archived forreconciliation and may provide a method for audit as well asreconciliation of requests and their status. This approach can protectthe participating data requestor/subscriber by providing a discretehierarchy of authentication within their business to ensure that thedata request is authentic, and the requesting party is authorized to doso. Data being handled may conform to the related data handling andsecurity policies, and the actual data may not be exposed. By scalingthe TAE deployments throughout their organizational points-of-presence,the participating data requestor may also provide for redundancy toprotect business operations against functional outages.

The TAE may be configured and deployed for a variety of networksettings, including virtual private networks, closed networks, cloudenvironments, or hybrid server environments. The TAE may be single ormulti-tenancy at both the data request originator level and thedatabases of identity level. A participating entity for the identitydata transaction system may choose to configure (or customer/data ownermay configure) the connectors and profiles on the configuration engines.Databases/engines and additional systems may be hosted in disparate,networked or single server environments. Computational logic may takeplace in a decentralized manner consistent with the implementationdescribed envisioned in these embodiments.

FIG. 10A illustrates another example hierarchical data flow in anidentity data transaction system 1000 that leverages identity databases1002A, 1002B, and 1002C at various levels. System 1000 includes a userinterface 1016 to process and analyze identity data provided by system1000. System 1000 also includes an identity discrimination programminginterface to blend in identity data from third parties.

User interface 1006 may interact with access controls service 1018. Anexample access control service 1018 may refer to workflow that includespresenting challenges to an end user whose identity is being verified,and receiving responses from the end user. The work flow through userinterface 1016 may include a user experience aspect, as annotated as UX.Access may be conditioned on matches (or substantial matches). In someimplementations, statistics of number of matches, number of trials,complexity of challenges/responses may be recorded and retrospectivelyanalyzed.

Internal routing rules engine 1008 may utilize participant businessprocesses 1004 and participant business intelligence 1006. Rules engine1008 may apply verification rules to identity data. Participant businessprocesses 1004 may include software services and processes for identityverification for the participant business. Participant businessintelligence 1006 may include statistics, rules, or analytics of theparticipating business. Participant business intelligence 1006 may beanalyzed by participant software services and processes 1004, the resultof which may be further processed by obfuscation/hashing service 1010.An example obfuscation and hashing may provide a one-way encryption notreversible by virtue of applying encryption or decryption key(s).

As illustrated, an identity discrimination programming interface 1014may leverage identity data from database 1002A. In analyzing suchidentity data, identity discrimination programming interface 1004 mayutilize third-party hardware data capture methods and systems tosupplement additional identity data from third parties. In someinstances, an enhanced identity profile 1010 may additionally providealgorithms and threshold levels for querying databases 1002A.

Identity discrimination programming interface 1014 may leveragecredential request service 1020A, computational algorithms service1020B, and biometric database registration service 1020C. Credentialrequest service 1020A may provide sources and types of credentialsrequired. Computational algorithms service 1020B may provide dispositionof trustworthiness. Biometric databaseregistration/presentation/obfuscation service 1020C may interface withdatabase 1002B so that identity data transaction system 1000 mayleverage identity data on database 1002B. The service may includeregistration of a digital identity stored on database 1002B,presentation of a digital identity, and obfuscation of a digitalidentity to generate, for example, an abstraction such as a hash of thedigital identity for transportation over a communication layer.

The above described components may be implemented as software layersresiding on transaction authentication layer 1022. The transactionauthentication layer 1022 may generate software events corresponding toprescribed conditions (such as assurance determination reaching athreshold level) or detected real-world events (such as leveragingidentity data arriving from a third party). The transactionauthentication layer 1022 may be provided over data requestersynchronization/prioritization layer, which in turn may be provided overa communication bus/access interface (1026) to trusted transactionengine (TTE).

FIG. 10B shows diagram 1030 illustrating the various service componentsof an example TAE. The various service components may interface witheach other over the TAE service layer 1040. The service components mayinclude credential request service 1032, policy management 1034,trustworthiness disposition service 1036, identity management service1038, process request service 1042, subscription management 1044, aswell as communication protocol management 1046. Credential requestservice 1032 may include setting the usage policy of the identity atpolicy management 1034, the matching criteria at trustworthinessdisposition 1036, as well as managing the identity claimed by thecredential request at identity management service 1038.

Meanwhile, a process request service 1042 may allow transaction requeststo be queued and prioritized. The process request service 1042 mayinteract with subscription management 1033 as well as communicationprotocol management 1046.

The Authenticated Validation Engine (AVE) may include computationalalgorithms prescribing the electronic means and workflow rules by whichthe participating entity (the identity provider) is permitted tointeract with the trusted transaction ecosystem and its agents offunctionality. Additionally, the AVE may define and deliver a set ofintermediary algorithms and results necessary to compute the “minimumlevel of trustworthiness” and may ensure the rules for completing thedata request are completed within policy compliance among contributorswithin the participating entity and between the parties engaged in atransaction event in the identity data transaction ecosystem, and withthe ecosystem itself.

In an example implementation, the AVE may include a combination of asingle or a plurality of sessions from data providers from within theircommon participant subnetwork (e.g., a company or jurisdiction with acentralized policy management hierarchy, but with distributed identitydata elements, a subset of which is being requested by another party inthe trusted transaction ecosystem).

Upon each request instance, local policy may dictate that elementsrelated to identity, trust, authentication, and security are beingadhered to. Examples of attributes may include, for example, thesoftware application, security environment, communications protocol,originating domain name server (DNS) and subnet, infrastructure such astransmission control protocol/internet protocol (TCP/IP), one or moresecurity protocols such as secure sockets layer (SSL) or a virtualprivate network (VPN) or public key infrastructure (PKI). Additionally,the AVE would query a centralized permissions/subscription enforcementengine, one or more centralized business rules expected for thetransaction, a single or a plurality of participating trusted identitydatabases, to extract and incrementally compute n input value for theminimum threshold of trustworthiness.

In an example implementation, commercial businesses, such as a bank, maydesire to verify the identity of an individual for a trustedtransaction. The requesting TAE may initiate a data query transaction.The request is transported through the trusted transaction ecosystem tothe participating data provider(s). The AVE may receive the request andself-configure itself based on the provided request specifications, suchas, for example, configurations for dataset, methods, expected responsetype, and security tokens. Based on the communications protocol, andsecured with technologies known to those skilled in the art, the systemmay verify the subscription of the data requestor, process the requestagainst pre-negotiated business rules, verify compliance with localpolicies and send the query to the trusted identity database. Thetrusted identity database in turn is configured to accept and reply todata query transactions based on a custom configuration that mayinclude, for example, verifying that the data requestor is not on ablack list, the requester has submitted a compliant query, and that therequest is in the proper format. Once validated as a complianttransaction, the query is performed and the database response isformatted for reply and sent back through the system, in reverse, to thedata requestor.

Some implementations may function as a “local” complianceengine—receives data requests from the trusted transaction ecosystem(TTE). Some implementations may function as mapping-defined “connectors”in a multi-tenancy environment, combining local rules and requirementswith the gaps of knowledge in order to determine programmatically whichpieces of information are missing, and which sources of data to query.Some implementations may function as a communications coding engine byreceiving (e.g., in a multi-tenancy environment) the pre-negotiatedprotocols, security, and data parameters that may be required for thebidirectional data transaction to take place, to ensure authenticity ofthe transaction is trustworthy. As deployed in a multi-tenancy,multi-instance solution, some implementations may decentralize thebusiness rules and data transaction elements of the data providingentity of the ecosystem. This decentralization may reduce impacts ofnegative events such as outages, while spreading the computational anddata burden across other AVEs deployed by the corporate identity dataprovider. Some implementations may function as an access“gate”—requiring biometric (or biometrically fused data), alone, or incombination with real-time data-hashing algorithms to ensure the datarequest is authentic (and not hacked or spoofed).

In some implementations, the authenticated validation engine (AVE) canbe deployed on a single server instance or across a federation of serverinstances. This engine then processes a “hash” of the request, thecommunication codes, and the requested target identity databases. Theserequests are archived for reconciliation and may provide auditinginformation as well as reconciliation of requests and their status. Suchimplementations may protect the participating identity data provider byproviding a discrete hierarchy of authentication within their businessto ensure that the data response is authentic and compliant with theirlocal policies, and that the providing party is authorized to do so.Data being handled will conform to the related data handling andsecurity policies, and the actual data may not be exposed.

By scaling the AVE deployments throughout their organizationalpoints-of-presence, the participating data provider may also provideredundancy to protect business operations against functional outages.The AVE may be configured and deployed for a variety of networksettings, including virtual private networks, closed networks, cloudenvironments, or hybrid server environments. The AVE may be single ormulti-tenancy at both the data request originator level and thedatabases of identity level. A participating entity for the identitydata transaction system may choose to configure (or customer/data owner)may configure the connectors and profiles on the configuration engines.Databases/engines and additional systems may be hosted in disparate,networked or single server environments. Computational logic may takeplace in a decentralized manner consistent with the implementationdescribed envisioned in these embodiments.

FIG. 11A illustrates another example hierarchical data flow in anidentity data transaction system 1100 that leverages identity databases1102A, 1102B, 1102C, and 1102D at various levels. System 1100 includes auser interface 1116 to process and analyze identity data provided bysystem 1100. System 1100 also includes an identity discriminationprogramming interface 1114 to blend in identity data from third parties.

User interface 1106 may interact with access controls service 1118. Anexample access control service 1118 may refer to workflow that includespresenting challenges to an end user whose identity is being verified,and receiving responses from the end user. Access may be conditioned onmatches (or substantial matches). The work flow through user interface1116 may include a user experience aspect, as annotated as UX.Statistics of number of matches, number of trials, and complexity ofchallenges/responses may be recorded and analyzed.

Internal routing rules engine 1108 may utilize participant businessprocesses 1104 and participant business intelligence 1106. Rules engine1108 may apply verification rules to identity data. Participant businesspolicies 1104 may include services and processes for identityverification for the participant business. Participant customer relationmanagement (CRM) and access constraints 1106 may include statistics,rules, or analytics of the participating business. Participant CRM andaccess constraints 1106 may be coupled to identity database 1102A toobtain CRM and/or access constraints data. Participant CRM and accessconstraints 1106 may be analyzed by participant software services andprocesses 1104, the result of which may be further processed byobfuscation/hashing service 1110. An example obfuscation and hashing mayprovide a one-way encryption not reversible by virtue of applyingencryption or decryption key(s).

As illustrated, an identity discrimination programming interface 1114may leverage identity data from database 1102B. In analyzing suchidentity data, identity discrimination programming interface 1104 mayutilize third-party hardware data capture methods and systems tosupplement additional identity data from third parties. In someinstances, an enhanced identity profile 1110 may additionally providealgorithms and threshold levels for querying databases 1102B.

Identity discrimination programming interface 1114 may leveragecredential request service 1120A, computational algorithms service1120B, and biometric database registration service 1120C. Credentialrequest service 1120A may provide sources and types of credentialsrequired. Computational algorithms service 1120B may provide dispositionof trustworthiness. Biometric databaseregistration/presentation/obfuscation service 1120C may interface withdatabase 1102C so that identity data transaction system 1000 mayleverage identity data on database 1102C. The service may includeregistration of a digital identity stored on database 1102C,presentation of a digital identity, and obfuscation of a digitalidentity to generate, for example, an abstraction such as a hash of thedigital identity for transportation over a communication layer.

The above described components may be implemented as software layersresiding on authentication validation layer 1122. The authenticationvalidation layer 1122 may generate software events corresponding toprescribed conditions (such as assurance determination reaching athreshold level) or detected real-world events (such as leveragingidentity data arriving from a third party). The authenticationvalidation layer 1122 may be provided over data providersynchronization/prioritization layer, which in turn may be provided overa communication bus/access interface (1126) to TTE. Data providersynchronization/prioritization layer 1124 may also couple to database1102D. Here, the databases may be external databases. In some cases,under a functional requirement for providing trusted identity, anoperating agreement or a legislative mandate, these external databasesmay be kept in synchronization with the identity data ecosystem. Theability to leverage external databases can be important for real-timefunction of accessibility/visibility, or even for disaster recovery.

FIG. 11B shows diagram 1130 illustrating the various service componentsof an example TAE. The various service components may interface witheach other over the TAE service layer 1140. The service components mayinclude process credential request service 1132, policy management 1134,trustworthiness disposition service 1136, identity management service1138, process request service 1142, subscription management 1144, aswell as communication protocol management 1146. Credential requestservice 1132 may include setting the usage policy of the identity atpolicy management 1134, the matching criteria at trustworthinessdisposition 1136, as well as managing the identity claimed by thecredential request at identity management service 1138.

Meanwhile, a process request service 1142 may allow transaction requeststo be queued and prioritized. The process request service 1142 mayinteract with subscription management 1133 as well as communicationprotocol management 1146.

Credentials for individuals and entities may be issued by a certifyingauthority, based on the data and privileges desired at the discretion ofthe certifying authority or with the certifying authority acting as anagent on behalf of an organization which likewise determines theprivileges. Because each certifying authority controls the aspects ofeach credential, credential holders may be limited in terms of the useof the credential.

Notably, credential holders in need of multiple credentials are issuedmultiple, discrete credentials by multiple certificate authorities, eachmay require independent maintenance.

Some implementations of an identity credential ecosystem may beelectronic or digital, yet likewise certifying-agency-centric. In theseimplementations, each organization may establish or manage acredentialing process, and the credential holders may have limited rolesand can only enjoy a narrow range of permissions-typically tied to oneset of use cases and permission sets. For example, management ofelectronic credential documents, including eIDs (electronic IDs),eWallets (payment tokens) and even FID-type (e.g., standards-based) andothers, typically revolve around one unifying ecosystem or mastercertificate authority that would manage the identity andrights/privileges of the credential holder/individuals.

Some implementations of digital IDs may include a certificate authoritybody providing the infrastructure of identity credential, in which aparticipating entity may manage the token identities of the holder.These implementations may create vetted/trusted identity tokens toenable identity related privileges and transactions. In theseimplementations, the tokens may be user-initiated and/oruser-configured. These implementations may provide an embodiment of theidentity data transaction system to enable users to manage theiridentities and associated permissions and transactions across multipleparticipants in the identity data transaction system. Theseimplementations may facilitate the enrollment, configuration and ongoingmanagement of a token-based identity as centrally managed by eachparticipant/consumer. In these implementations, the paradigm may bechanged from the establishment and management of a credential on behalfof central and authoritative CA (certificate authority), to a modelwhereby the identity transaction system brokers credential managementtransactions on behalf of the user, thereby enabling the user to requestand obtain roles and permissions according to multiple user-specifiedscenarios. In these implementations, the CA interacts with the identitytransaction system (e.g., according to business rules on policy engines)to determine if and how the permissions will be granted in an automatedfashion without the need for human mediation (except that humanmediation is possible in a system administration capacity).Specifically, some examples may incorporate a trustworthiness scorebased on the underlying privileges and permissions. Some examples mayconfigure preferences for identity databases to participate in theecosystem (such as the identity data transaction system). Some examplesmay configure preferences of the subscribers (enterprise participants)to the identity data transaction system.

Some implementations provide software, systems, methods andphysical/digital outputs to enable the deployment and use of identitytokens on portable computing devices where the user initiates andauthorizes the privileges associated with the credential. In an exampleimplementation, such token may be first authorized by a qualifiedcertificate authority such as, a government agency or officialorganization. In another example implementation, such token may beinitiated by a user, and managed by an identity data transaction system.In an example implementation, physical/digital outputs (such as aphysical identification document or a digital identification document)may include a token that represents a single set or plurality of sets ofprivileges associated with a trusted and vetted identity. In thisexample, such token/entities may be configured as instances that areenabled for different permissions and configurations based onindividually configured relationships with different participants of theecosystem (such as the identity data transaction system). In yet anotherexample implementation, such tokens may be established, configured,managed, revoked (or set to expire) by the user/credential-holder at theuser discretion. In this example, permissions associated with the tokensare configurable such that if one permission is revoked (or hasexpired), other permissions sets may remain intact until likewisemanaged or revoked specifically to enable the ability for a “temporary”or “one time” token artifact.

Some implementations may provide access to a central repository ofidentity-related credentials and documents. In these implementations,the access may be enabled and facilitated by the trusted identity tokenand its associated privileges. Some implementations may allow consumerusers to self-generate digitally-watermarked physical credentials formachine validation. Some implementations may allow for integration intoidentity-related security technologies including, for example, smartcard/token based security systems, public/private software keycombinations, and thick client biometric software and hardwareperipherals.

Some implementations may enable the creation and configuration ofdigital tokens that can be used to execute privileges. In one example, auser may conduct trusted transactions associated with the user'svetted/trusted identity according to the privileges established with oneor a plurality of credential authorities. In this example, theconfiguration and control of such privileges and permissions aremastered by the user. Notably, features of some implementations mayinclude the ability for the user to initiate and/or configure one or aplurality of instances of a credential and its associated permissionsthrough a unified interface on a computing device.

In some implementations, the user may have established, as part of anenrollment process, a primary trusted identity meeting enrollmentcriteria from a qualified certificate authority such as, for example, agovernment agency (such as a department of motor vehicles, animmigration agency), an official organization (such as a university,hospital or financial institution), or a commercial organization (suchas a provider of identity services). The token issuers may also includeproviders of trusted identity data.

In some implementation, a user enrolls for a credential with a trustedcertificate authority, and provides sufficient proof-of-identitydocuments and/or data so as to establish a trusted identity with thatentity. By way of illustration, that entity may initiate, according tobusiness practice, one or more additional data queries at an identitydata ecosystem for identity verification. The identity data ecosystemmay include a federated system of identity databases from varioussources, including, a government agency (such as the U.S. SocialSecurity Agency or the Veterans Administration), a commercial entity(such as a financial reporting organization such as EXPERIAN), or anorganization of higher learning (such as a university) in order tofurther vet the identity and/or increase the confidence in the identity.Notably, the user data may also be cross-correlated to additionalnegative-indicator databases such as a watch list, problem driver list,sex offender list, the FBI felony database or other source of data thatmay restrict the users permissions. These organizations may be insideand/or outside a formal ecosystem, enabling data queries with thirdparties that do not participate in the ecosystem as a tertiaryvalidation check. The identity data eco-system may provide a scoringmethod for ranking the quality of the trusted identity on one or moredimensions including but not limited to identity surety, or risksassociated with the identity. In some implementations, the identity dataeco-system may incorporate multiple forms of identity data, such asbiometric data elements to provide added confidence level in a givenauthentication as well as multi-factor authentication.

Some implementations may provide a user with a foundational credential.The foundational credential may be digitized into a digital token,including, for example, an electronic ID, or other unique identifier.

Some implementations may include a “plurality token.” The pluralitytoken may include a collection of tokens, or a token with multiple setsof discrete characteristics to serve as multiple tokens for differentpurposes. By way of illustration, such plurality tokens may be machinereadable, machine validated, or human verifiable. Specifically, suchplurality tokens are extensible to incorporate more than one set ofidentity data including, for example, multiple aliases. For instance,each set of identity may be associated with a particular set of rolesand permissions. In these implementations, a persistent identity datasetmay include a unique identifier across the identity data eco-system.

Example plurality token sets may be secured by authentication. In oneinstance, the unique identifier across the ecosystem may be enabled formulti-factor authentication including, for example, biometrics,password, PIN numbers, or challenge/response. Each set of identity maybe authenticated by its own biometrics, password PIN numbers, orchallenge/response. As noted, the plurality token may include acollection of tokens, or a token with multiple discrete characteristicsserve as multiple tokens for different purposes. During the enrollmentprocess, the token unique identifier may be established, and may then becryptographically tied to the user with an encryption scheme that,amongst its decoding protocols, includes multi-factor authenticationsuch as a biometric (e.g., facial recognition, fingerprint, or voice).In one example, a multi-factor authentication including, for example, aPIN number, a key phrase, or secondary biometric, may greatly reduce thechances of another human being having same combination. Theauthentication may further include mechanisms to thwart, for example,replay attacks. Such mechanisms may incorporate a measure of freshnessor liveliness, for example, by asking the requester to provide evidenceof a live session. In one instance, the requester may be asked to entera pseudo-random verification code unique for each session. In anotherinstance, the pseudo-random code may be dynamic to thwart furthercrawler/robot attacks. Such measures may also include associating freshcharacteristics for each requesting session, for example, generatingcharacteristic data unique for each session and coupling thecharacteristics with a password, a biometric, a PIN number, etc.

The level of authentication sophistication may vary with the underlyingroles and permissions associated with each set of identity. Thesophistication level for each identity set may be adjusted by theuser/consumer on his/her own initiative. Some implementations may allowthe user to have control over the use of their trusted identity tokensand associated privileges. Since users can have more than one credentialand can combine their credentials into a unified, multi-purpose“plurality token.” For example, the user may have a core or foundationtoken. The core or foundation token may be used to back up otheridentities, each with its own set of permission and privileges. Accessto the core or foundation token may enable access to other tokens. Theuser, however, is enabled, for example, through a user device, to modifypermissions and privileges for each identity (including, for exampleinitiating, expiring, or disabling temporarily). This configurationcapability can happen at each token level, and can happen even at the“core” token, within constraints defined by the identity data system. Insome implementations, such configuration may be performed over a network(wired or wireless) so that the permissions and privileges for eachidentity at remote identity databases can be managed by the user.

In some implementations, the “plurality tokens” may be managed through acertificate authority of the identity data eco-system. This certificateauthority may acts as a proxy for multiple third-party orecosystem-based certificate authorities, and may operate under policiesadministered through the identity data eco-system.

Notably, the token may be installed or uploaded into a device of theuser's choice, including, for example, a mobile tag, a smartphone/tablet, a portable computing device, a dongle, a NFC/RFID or otherdevice capable of electronic communication.

Once the token is enabled, the token is activated with an underlyingtrusted identity. The trusted entity may be in an encrypted form andlocked to the user's identity, which may present a physical identitydocument of the user. The enabled token can be used to authenticate to aregistry service of the identity data eco-system. The use may furtherconfigure the token to define, for example, the types of transactionsenabled by a successful authentication based on the token. The registryservice may require authorization from the user to use the newlyconfigured token, and may need the authentication that the token isvalid. In this manner, the user may interface directly to the identitydata eco-system, as well as the proxy certificate authority andassociated policy engines. As an additional layer of security, atemporary PIN number assigned by the identity data eco-system mayfurther secure the registry transaction from unauthorized access.

The registry may create a unique identifier, for example a token typeID, a hash of the token ID or serial number combined with a uniqueidentity ID and a secondary hash of one or more of the multi-factorauthentication templates, thereby creating a unique identifier stringunique to that User. This unique identifier may be encrypted uponcreation, and can be reduced in string size by applying a hash, adigest, a checksum, or other algorithmic shortening. Once the identitytoken has been defined and secured, the identity token may be tied tothe physical identity of the user.

Some implementations may include a user-controlled permissions system.In this system the user can, for example, establish multiple tokenidentities, define the entities that have permissions to access theusers credential, configure those permissions, suspend (or set toexpire) the permissions on an entity by entity or permission bypermission basis, and revoke tokens or permissions (e.g., on an entityby entity or permission by permission basis).

To expand on the registry account further, a user may have a trustedgovernment identity loaded as a secured token. In one illustration, theuser may have used that identity token to submit his or her fingerprintsto the FBI. Thereafter, the user may have been licensed to carry aconcealed weapon. Such authorization may be encoded into the particularidentity token. The user may, at the same time, maintain anotheridentity token encoding an authorization to fish in particularjurisdiction. Thus, some implementations may allow one person to havemultiple credentials with associated permissions and managed in a singletoken set, and managed by the user himself/herself.

Once installed on a user device and locked by virtue of multi-factorauthentication, the identity token may be used by the user in trustedtransactions where identity matters. Examples of transactions mayinclude one-time or low incident but high risk transactions such aslarge-sum financial transactions, enrollment in institutions of higherlearning, providing proof of identity for trusted transactions such asobtaining a concealed carry weapons permit or background checks. Exampletransactions may further include recurring transactions, such as usingan ATM machine, using public transportation, obtaining health care,picking up children from daycare, or other recurring transactions.

In some implementations, an identity token may be used as the accesscontrol for a repository of identity-related data and document. Forexample, an identity database, such as an “identity vault,” may be undersuch access control. By way of illustration, the identity token may beused for access control of a physical safety deposit at a local bankwhere physical items can be kept (for example, jewelry, birthcertificates, or physical keys). The identity token may be used foraccess control of other safety premises (such as a firearm safe, or acontrolled substance safe).

In some implementations, the user can generate on a portable computingdevice, a digitally-watermarked credential. The credential may bedisplayed on a portable computing device, in printed form, or other, asa means of providing a physical token that can be validated/verifiedwith a machine/scanner configured to identify and decode digitalwatermarks.

Some implementations may be practiced in a variety of network settings,including virtual private networks, closed networks, cloud environments,or hybrid server environments. The network may be a single ormulti-tenancy setting at both the data request originator level as wellas the databases of identity level. A participating entity for theidentity data transaction system may choose to configure (orcustomer/data owner) may configure the connectors and profiles on theconfiguration engines. Databases/engines and additional systems hostedin disparate, networked or single server environments. Computationallogic may take place in a decentralized manner consistent with theimplementation described envisioned in these embodiments.

FIG. 12A illustrates a token management architecture 1200. The token maygenerally refer to a certificate specifying a set of privileges orpermissions for the carrying (or associated) party, for example, users1204A, 1204B, and 1204C. The carrying (or associated) party of a tokenmay use the granted token to obtain access to, for example, a useraccount, an application program, a bank account, a virtual vault, and/orrely upon the token for physical access control to items and locations,such as, for example, a personal car, a rental car, an enterprise, afacility, a repository, a physical vault, an asset, a facility, asubway, a ballpark, a plane, a port, a school. The token may beconfigured to act as a password in certain cases. A certificateauthority (CA) 1202 may include an administrative agency or regulatoryauthority charged with granting or administering access based on a tokenfor the benefit of a party that applied for the token. The certificateauthority also may be configured to revoke or suspend the token held bya party. An example of a certificate authority may include, for example,a financial institution (e.g., a bank, a credit union, an investmentcompany, a mutual fund company, a payment brokerage company, a creditcard company), a government agency (e.g., The Social SecurityAdministration, the Department of Health and Human Services), a facilitymanager, or an educational institution. In one work flow, an associatedparty may apply for a token at a particular certificate authority. Eachcertificate authority may administer a corresponding set of rules ofprocessing the applications to determine whether an applicant isproperly identified. The scope of permissions associated with anapplicant may specify access and permissions to a particular onlineaccount or a physical building, and/or a duration of privileges for anapplicant. The particular certificate authority may elect to screen anapplicant according to a set of rules for a particular service orsystem. After an applicant has been authorized pursuant to the screeningprocess, the certificate authority may issue a token. As noted above,the token may allow the carrying (or associated) party to have theaccess privileges and permissions as specified by the token. The tokensmay be configured to be issued in a “one way” manner, from thecertificate authority to, for example, individual users. As illustratedin FIG. 12A, a particular certificate authority may issue tokens tomultiple users, each allowing the recipient user to have the specifiedprivileges and permissions. In other words, the one way characteristicmay form a hub and spoke pattern with the particular certificateauthority at the center.

A certificate authority may employ advanced feature sets for screeningapplicants and/or issuing credential tokens. For example, a certificateauthority may attempt to manage a subscriber community with increasinglysophisticated measures intended to more robustly verify user identity.However, an individual user, especially a less sophisticated user, maybe intimidated by the number of credential tokens issued from variouscertification authorities, such as a user's school, bank, credit cardcompany, employer, retirement services agency, the Social SecurityAdministration, a health insurance provider, the user's auto insurancecompany, a user's mortgage company, a user's health club, a primary carephysician, a user's social network account. Each of these CAs mayinclude different measures, configurations, and risk levels forauthenticating the carrying party of a credential token. The sheernumber of credential tokens from these certification authorities mayonly grow as the society becomes increasingly a digital society.

For some users, managing such an array of tokens may become problematic.For example, an average user may forget passwords for certain accountsand may resort to resetting passwords frequently. A user may opt to usethe same password for multiple accounts, which may compound the impactof a breach on one account. A user may resort to writing passwords foreach account on a piece of paper, or a single file on a disk, the lossof which may lead to adverse consequences.

Moreover, users may be forced to rely upon a difficult-to-use token andthe associated CA-centric control system. In order for recipient A togrant access rights to recipient B (a different user), recipient A maypass the token that recipient received from the certificate authority torecipient B. This passing of the token may increase the risk of identitytheft in the digital age.

FIG. 12B illustrates a system 1210 configured to address some of thesechallenges. As shown, a two-way user-centric pattern may enable a user,such as users 1212 and 1214, to configure privileges and permissions tothe user's asset or account based on a foundation token issued to theuser. Notably, some implementations may allow a user to requestpermissions or request artifacts or endorsements be added to the user'stoken set. Specifically, an individual user may submit the request forthe permissions, and then the certificate authority—within the businessrules of the certificate authority—may approve the request forpermissions, or reject the request for permissions. In other words, justbecause an individual user requests a permission or privilege to beassociated with the individual user, does not mean that the certificateauthority is obligated to approve the request for the permission orprivilege. For example, a credit card company may have internalguidelines to determine the credit limit to a request for a creditauthorization. Some implementations may include screening against anegative records database. The negative records database may range froma “bad guy” identity database to a counterpart (or third-party)certificate authority that can revoke a credential token (in thetraditional sense of a certificate authority). Not all “negative”decisions represent actions associated with bad intent. Some negativedecisions may represent actions with respect to expired accounts, ortemporarily unavailable identities.

As illustrated in FIG. 12B, a user may start with a foundation token.The foundation token also may be known as a primary identity document. Afoundation token may be issued based on (or premised on) a primaryidentity document issued by, for example, a government agency after arigorous vetting process. This example may allow the plurality token setto leverage the authority and trustworthiness associated with suchgovernment identification documents or the vetting process thereof. Inthis illustration, the foundation token may be issued by one of CAs1216A to 1216C. Some examples of a digital foundation token may include:a digital portrait, a digital passport, a digital driver license, etc.Because a vetting process implemented by some entities (e.g., agovernment authority) may authenticate a person (or an entity for thatmatter) in a manner that provides an increased degree of confidence, thetie-in of such a record having a high degree of confidence (i.e., a“golden record” or “system of record”) into the ecosystem carries withit the gravitas of that identity endorsement. For instance, the state ofMassachusetts Department of Motor Vehicles (DMV) may personallyauthenticate using measures associated with a high degree of confidencebefore the DMV issues the user the foundation token (i.e., the driverlicense). The credential of the driver license and the associated recordhave more value than an identity backed by an non-traditional sourcesuch as Facebook where Facebook may take a user's word at face value.Hence, by extending the use of that foundation token into a “certified”token set, the certified token set carries with it that identityendorsement.

Some implementations may allow a user to take the initiative to extend atoken set based on the foundation token. The combination of thefoundation token and the user initiative can provide a level of veracityand authenticity backed by the foundation token while maintaining theease of management through the user initiative.

Notably, extending the privileges from the foundation token may extendthe confidence for proposed (pending transactions) that can be linked toa trusted entity. In particular, the link to government-issuedidentities, or even official commercial enterprise, may provide themissing link of veracity of the underlying foundation token. Yet,additional value may be realized to include extending the individualuser's ability to manage and control their token-facilitatedtransactions through one token set. The token set may be scalable insize and extensible to new platforms as they are developed.Figuratively, the foundation token may serve as the ring or thekey-chain to tie all credential tokens that an individual user mayreceive from certification authorities. In contrast to the one to manymapping from one certificate authority to many users, someimplementations may provide many-to-many mappings between two individualusers. Here, the plurality is in the user managing a token system tiedby a foundation token versus certification authorities issuing multipletokens which users manage separately on a token by token basis.

Through the user initiative, some implementations may allow a user todelegate portions of permissions and privileges of the user to anotheruser. For example, the user may have, as part of the user's identitytoken maintained with regard to access a local gym or library, thepermissions and privileges to access gym or library facilities duringvisits on premise between 9 am and 5 pm local time. In this example, theuser may delegate such permissions and privileges to the user's childwhen the child is away from school in summer time. The delegation may belimited to the user's child only and may be limited to summer months. Ina similar vein, delegation through token configuration may allow theprincipal user to assign portions of the principal's permission andprivileges to another user in the capacity of an agent. In the aboveexample, during school season, the parent may delegate, to schoolofficials, the permission and privileges to configure access right ofthe child to school facilities on premise. Such delegation may alsoinclude the access right of child to use local medical facilities. Inthese delegation examples, the parent may issue a token to the receivingparty. The token may be combined with the receiving party's foundationtoken so that the receiving party may use the foundation token toauthenticate the receiving party's identity in order to enjoy thedelegated right or perform the delegated task.

Some implementations may allow a user to impute portions of permissionsand privileges of the user to another user. For example, the user mayenjoy access rights to an on-line banking facility. Through tokenconfiguration, the user may impute such permissions and privileges to aspouse, or trusted family member. As a result, the spouse or trustedfamily member may enjoy the same access rights at the on-line bankingfacility. The imputation may be realized by the user issuing a token tothe receiving family member. The token issued by the user may rely onthe receiving user's foundation token to authenticate the receiving userat the on-line banking facility.

FIG. 13 shows an example process 1300 for a server of a certificateauthority to interact with a user according to some implementations. Asan initial matter, the user may be in possession of an identificationdocument issued by a trusted entity through a rigorous vetting process.The identification document may function as the foundation token. Herethe trusted entity may generally include an authoritative governmentagency, such as, for example, the state department at the federal level,the department of motor vehicles at the state level. The trusted entitymay also include other authoritative sources such as, for example, anaccredited educational institution, or an employer with a rigid vettingprocess to authenticate employees. The identification document mayinclude a digital passport, a digital driver license, a digitalportrait, a digital permanent resident card, a digital national identitycard, etc. In some implementations, the identification document mayinclude traditional physical identification documents. The vettingprocess may include the process of proving that an applicant is properlyidentified, based on, for example, physical examination, facialrecognition, inspection of birth certificate.

The user then may submit a request for associating an index ofprivileges and permissions to the foundation token, for example, adigital portrait issued by a trusted entity. The request may besubmitted along with a foundation token of the user. The index ofprivileges and permissions may be known as a credential token. The indexof privileges and permissions may encode the scope of permissions forthe user to, for example, access transactional data managed orcontrolled by the certificate authority. In some implementations, thetransactional data may be merely under the custody of the certificateauthority. The privileges and permissions may also encode a durationduring which the user may access the transactional data.

The request may be received at a server (1302). The server may belocated at the certificate authority. The server may then extract thefoundation token from the request (or information related to afoundation token) (1304). Thereafter, the server at the certificateauthority may validate the foundation token as authentic (1306). Thevalidation may include verifying the format of the foundation token asin conformance with jurisdictional requirements, verifying that acomputed checksum from a particular segment from the foundation tokenmatch a corresponding recorded checksum for the particular area,cross-correlating information from various segments on the foundationtoken, confirming with the trusted entity that has issued the foundationtoken, or verifying with a third-party identity broker that can attestto the validity of the foundation token.

In some implementations, the validation may further includeauthenticating that the user submitting the request is the personidentified by the foundation token. For example, the validation mayinclude matching a biometric value of the submitting user with thecorresponding biometric on the foundation token. The biometric value mayinclude, a face, a finger-print, a palm-print, an iris scan, a retinascan, a voice, a gait analysis, etc. By way of illustration, someimplementations may include automatic facial recognition to compare theface of the submitting user matches the face shown on the foundationtoken. To mitigate spoofing or other fraudulent measures, the submittinguser may be prompted to gesture in a manner that cannot be predicted byinjecting a static image as a man-in-the-middle attack.

The validation may establish that the foundation token is authentic andhas not been tampered with (or at least indicate that the presented datahas been analyzed using certain filtering processes that address certainfraudulent techniques). The validation also may validate that submittinguser is the user identified by the foundation token. Thereafter, theserver at the certificate authority may further compare the requestedpermission and privileges with internal business rules to determinewhether the requesting user can have the requested permissions andprivileges.

By way of illustration, if the requesting user is requesting access tobuilding A, the server at the certificate authority may determinewhether the requesting user is prohibited from entering building A. Forexample, the server at the may verify whether the requesting user has anoffice in building A, whether the requesting user is on a black-list tovisit building A, whether the requesting user has paid commensurate feesto visit building A at a particular time, or whether the requesting userhas other legitimate business reasons to visit building A at theparticular time.

In another illustration, the requesting user may be requesting temporaryaccess rights for a different user. In this case, the server at thecertificate authority may verify whether the requesting party isauthorized to grant access rights to a third party, for example,regarding the transactional data in question.

Once the server at the certificate authority determines that therequesting user may have the requested permission and privileges, theserver at the certificate authority may add the credential token to therequesting user's token set (1308).

In yet another illustration, the server at the certificate authority maycause the requested privileges and permissions to be associated with thefoundation token. In one example, the server at the certificateauthority may generate an add-on credential token and transmit the sameback to a computing device of the user. The credential token may includedata encoding an index for the requested permissions and privileges. Thedata may be encrypted using a private key of the certificate authorityand a public key of the user. Upon receipt, an application program onthe user's computing device may decrypt the encrypted data by using theprivate key of the user and link the credential token to the foundationtoken. The user may now have a token set linking the newly receivedcredential token to the foundation token. The user may subsequently linkmore credential tokens to the same foundation token and extend the tokenset.

In yet another example, the server at the certificate authority mayattach data encoding the requested privileges and permissions directlyto the foundation token. The attachment may take the form of appending,embedding, steganography, etc. The attachment portion may be encryptedusing a private key of the certificate authority and a public key of theuser. Upon receipt, an application program on the user's computingdevice may decrypt the encrypted portion of the foundation token byusing the private key of the user. The user may now have the foundationtoken extended to include the newly obtained privileges and permissions.The user may subsequently extend the foundation token to privileges andpermissions obtained from other certification authorities or link morecredential tokens to the same foundation token. Hence, the user maytreat the foundation token as the master ring or key chain to tie incredential tokens obtained from participating certification authoritiesin an eco-system.

FIG. 14 highlights the process 1400 for a user to request sets ofprivileges and permissions to be added to a foundation token of the useraccording to some implementations. A consumer user may have anapplication program installed on a computing device of the user. Theapplication program may provide the user with an interface to specify aset of privileges and permissions to be associated with the user inaccessing transactional data (1402). The transaction data may be, forexample, managed by a certificate authority. The interface may include agraphic user interface to provide more intuitive experience for a userto specify a set of desired privileges and permissions at a particularcertificate authority. In one configuration, the interface may provide abatch processing capability for the user to submit multiple sets ofdesired privileges and permissions at various participatingcertification authorities. The batch processing capability may allow auser to obtain multiple sets of desired privileges and permissions atvarious participating certification authorities through, for example,one click, one key stroke, or one tap, on the computing device.

Thereafter, the computing device of the user may transmit a request tothe certificate authority as referenced by the request (1404). Therequest may be accompanied by a foundation token of the user. Sometimes,the foundation token may be referred to as primary identificationdocument. The foundation token may identify the holder of the foundationtoken by encoding a biometric of the holder. The foundation token may beissued by a trusted entity through a rigorous vetting process. As notedabove, a server at the certificate authority may process the request byverifying that the foundation token is valid. The server may alsoauthenticate that the requesting user is the holder of the foundationtoken. The server may additionally confirm that the requesting usermeets the pre-requisites for requesting the desired privileges andpermissions. For example, when the requesting user attempts to engage inage-restricted activities, the server may perform an age calculation toconfirm that the requesting user meets the age requirements. In anotherexample, when the requesting user attempts to have access to restricteditems, such as controlled substances, guns, ammunitions, etc., theserver may check the request against rules. The rules may limit theamount, duration, or time-window of accessing such restricted items. Ifthe request complies with the rules, the server at the certificateauthority may allow the request to proceed.

The computing device of the user may receive a response from the serverat the certificate authority (1406). The response may indicate that therequest has been approved or disapproved. In some implementations, ifthe request has been approved, the user computing device maycomputationally associate the requested set of privileges andpermissions with the foundation token of the user. In someimplementations, however, if the request has been approved, the usercomputing device may receive data encoding the foundation token that hasalready been computationally associated with the desired privileges andpermissions. The computation may have been performed by the server atthe certificate authority.

As noted above, the envisioned work-flow may enable a user to take theinitiative to configure and manage a token set of privileges andpermissions. For example, when the user has obtained a credential tokenfrom a certificate authority encoding the set of privileges andpermissions of the user, the user may take the initiative to revoke,renew, replace, or update the credential token. By way of illustration,the user may submit the revocation, renewal, replacement, or updaterequest through the same interface as noted above. The revocation,renewal, replacement, or update requests may be processed by the serverat the certificate authority in a manner consistent with the descriptionherein.

Similarly, the user has the initiative to add credential tokens fromother certification authorities to the same token set based on thefoundation token. By way of example, the user may submit additionalrequests for associating a new set of privileges and permissions withthe foundation token (1408). The submission may be through the sameinterface as noted above. The submission may be accompanied by thefoundation token of the user. The foundation token may already becomputationally associated with privileges and permissions atcertification authorities that the user has previously dealt with. Thenewly submitted request, however, may attempt to extend the foundationtoken to the new set of privileges and permissions so that the user mayobtain the new set of privileges and permissions. The new set ofprivileges and permissions may indicate the scope of right of the user,for example, to access transactional data managed by a certificateauthority that the user has not dealt with before.

The server at the new certificate authority may process the request inaccordance with the descriptions herein. If the request is approved,then the server at the new certificate authority may cause thefoundation token to be computationally associated with the additionalset of privileges and permissions. Further, the user may receive, on theuser device, data encoding a digital identity associated with the newlyrequested set of privileges and permissions (1410). Notably, thefoundation token is also associated with that existing set (or sets) ofprivileges and permissions. In other words, if the request is approved,the requesting user may have the additional set of privileges andpermissions attached to the foundation token that has been associatedwith existing sets of privileges and permissions.

The benefits may not be limited to the disclosure above. Someimplementations may allow a consumer user to upgrade from a physicalidentification document to an electronic identification document, forexample, at license renewal time. The renewal may be initiated from amobile computer device. The renewal time could also correspond torenewal time of a physical document. The electronic identificationdocument may be one example foundation token. A digital driver's licensemay be one example of an electronic identification document. By way ofillustration, a digital driver's license may be stored on a smart phoneor a consumer user and may be presented on the touch screen of the smartphone.

Some implementations may allow a consumer user to add new securityfeatures to the consumer user's eWallet solutions. Some implementationsmay a consumer user to add security features to the consumer user'ssocial network account, such as, for example, a Facebook account, aTwitter account.

Some implementations may facilitate Single Sign-Ons. Particularly, someimplementations may allow a consumer user to prove the consumer user'sidentity from a variety of contexts or situations.

Some implementations may allow a consumer user to incorporate a numberof credentials or endorsements into a foundation token of the consumeruser. The credentials and endorsements may include first responders,state employee ID, professional licenses, etc.

Some implementations may allow a consumer user to update data to anauthoritative source such as the DMV at a time chosen by the consumeruser. The updates may include, for example, address changes, donorstatus, veteran status. Some implementations may allow the consumer userto reinstate or revoke a driver license (or other endorsements) of theconsumer user in a real-time manner.

Some implementations may allow a consumer user to assert an identity ofthe consumer user from a variety of platforms, including, for example,mobile platforms, table devices, desktop PCs, or Web browsers.

Some implementations may allow a consumer user to use facial biometricswith a digital driver license for verification.

Some implementations may extend a foundation token to include othercredentials for a consumer user. In one example, a consumer user mayback a credit card application by using a digital driver license of theconsumer user. In another example, a consumer user may link apoint-of-service (POS) digital Medicaid card to a foundation token. Thelinked credentials may be used in a request for proposal (RFP) response.

Some implementations may integrate the use of digital driver's licensewith OpenID. Some implementations may accommodate using digital driver'slicense to support Single Sign-On (SSO). Some implementations may use afoundation token with eWallet to support an identity of the consumeruser in possession of the foundation token and the eWallet. Someimplementations may verify an identity of a state employee (for example,case workers) in connection with a digital driver's license of theemployee. Some implementations may verify an identity of a Medicaidbeneficiary based on a digital driver license of the user holding theMedicaid beneficiary card. Some implementations may allow a consumeruser to apply for benefits under a DHHS program by using a digitaldriver's license. Some implementations may allow a consumer to makecredit card purchases by authenticating the consumer according to adigital driver license. Some implementations may include conductingbackground check for applicants (for example, coaches, teachers, etc,)based on digital driver's license. Some implementations may facilitatehome healthcare uses with digital Medicaid card.

The systems here may be configured to support Internet, virtual, orIT-centric systems. For example, the system may be configured to linkdifferent internet connected systems so that an Internet banking systemmay be linked to support more elaborate operations within a socialnetworking system (e.g., share data or purchase prints). Theinternetworking may rely upon public networks (e.g., the Internet) orprivate (e.g., a government, corporate or private financial network). Inone configuration, the systems are configured to support enterprise IPnetworks. For example, the systems may be configured to support anenterprise financial payment system that pays outside vendors.Disbursements below a threshold amount may require that an administratorauthorize a transaction using input from a driver's license (e.g.,reading optical and authorization data from a driver's license readingsystem) with an enterprise social network (e.g., an intranet) configuredto interface with a user-centric identity management system. Fortransactions involving disbursements above a threshold, a passportreading system may be required to interface with an identity managementmodule that requires a first identity module for a first user tointerface with a second identity management module for a second userwhere the second user endorses the authorization of the first user.

The system may be configured to support virtual implementations where anidentity management module is managed and controlled by the user. Theuser may authorize other modules to interface with the virtual machinemanagement the identity. The virtual machine may act as a certificateauthority and key manager or delegate other systems to act ascertificate authority or key distributor on behalf of the user.

As noted above, the systems may be configured to create tokens thatreflect the authorization from multiple software and/or hardware systems(e.g., a physical token such as a printed driver's or a hybrididentification document such as a digital driver's license resident on amobile phone). For example, the user may wish to create a configurationthrough their identity management module whereby high risk transactions(mortgage and credit card applications) require both presentation of adigital token that reflects a sequence of authorization using both amessaging account (e.g., Google's Gmail service), a social networkingaccount (e.g., Facebook), and a user presenting a passport through apassport-reading application. The authorizations may be structured sothat a first service acts upon information authenticated by the priorservice. Thus, a messaging time stamp may be processed to create adelegated Facebook token that is received by a passport processingapplication. The passport processing application may opticallyinterrogate the passport based upon the received Facebook token. Theresultant token received from the passport reading application may bepassed onto a banking system for approval by a user's virtual identitymanagement agent. The resultant hybrid token may be physically presentedin the form of an electronic device (electronic ID or electronic IDapplication resident on a smartphone) to another user (e.g., anauthorizing official at the bank) who in turn presents their own digitalcredential. Alternatively or in addition, the transaction may beperformed between software and server agents acting on behalf of theuser and remote system (e.g., banking system). The user may configurethe token so that the token may be accessed and relied upon by a firstuser (e.g., a first bank) but not a second user (e.g., a second bank).The user may specify a list of agents authorized to rely upon and accessthe particular token.

The resultant token may feature a drill down or hierarchical featureset. For example, in a first case, a user may create a general tokenthat is used in a credit application for general applicability. The usermay specify that a pool of banks are authorized to consider a creditapplication so long as the bank is participating in the accreditedapproval system and/or specifies parameters in terms of certain ratesand parameters. One or more banking systems may accept the preliminaryrequest and contact the user's identity management module in order toreceive more information. The user then may modify their token toinclude a more detailed credit application and only authorize the moredetailed information for specified institutions.

The user agent may be configured to act as a user-controllable keymanagement agent and/or certificate authority that selectivelydistributes keys, delegates authority, and acts as a certificateauthority on behalf of the user. The user may specify one or more remotesystems with whom the user agent is authorized to act as a certificateauthority (CA), exchange keys, and/or share delegate information. In oneconfiguration, the user may instruct their agent, perhaps resident on orhosted on a virtual machine accessible through a mobile device, to use afirst set of keys to support financial transactions less than aspecified threshold for vendors willing to authenticate in a specifiedfinancial transaction network.

Various implementations of systems and techniques described here can berealized in digital electronic circuitry, integrated circuitry,specially designed ASICs (application specific integrated circuits),computer hardware, firmware, software, and/or combinations thereof.These various implementations can include implementation in one or morecomputer programs that are executable and/or interpretable on aprogrammable system including at least one programmable processor, whichmay be special or general purpose, coupled to receive data andinstructions from, and to transmit data and instructions to, a storagesystem, at least one input device, and at least one output device.

Computer programs (also known as programs, software, softwareapplications or code) include machine instructions for a programmableprocessor, and can be implemented in a high-level procedural and/orobject-oriented programming language, and/or in assembly/machinelanguage. As used herein, the terms “machine-readable medium”“computer-readable medium” refers to any computer program product,apparatus and/or device (e.g., magnetic discs, optical disks, memory,Programmable Logic Devices (PLDs)) used to provide machine instructionsand/or data to a programmable processor, including a machine-readablemedium that receives machine instructions as a machine-readable signal.The term “machine-readable signal” refers to any signal used to providemachine instructions and/or data to a programmable processor.

Suitable processors for the execution of a program of instructionsinclude, by way of example, both general and special purposemicroprocessors, and the sole processor or one of multiple processors ofany kind of computer. Generally, a processor will receive instructionsand data from a read-only memory or a random access memory or both. Theelements of a computer may include a processor for executinginstructions and one or more memories for storing instructions and data.Generally, a computer will also include, or be operatively coupled tocommunicate with, one or more mass storage devices for storing datafiles; such devices include magnetic disks, such as internal hard disksand removable disks; magneto-optical disks; and optical disks. Storagedevices suitable for tangibly embodying computer program instructionsand data include all forms of non-volatile memory, including by way ofexample semiconductor memory devices, such as EPROM, EEPROM, and flashmemory devices; magnetic disks such as internal hard disks and removabledisks; magneto-optical disks; and CD-ROM and DVD-ROM disks. Theprocessor and the memory can be supplemented by, or incorporated in,ASICs (application-specific integrated circuits).

To provide for interaction with a user, the systems and techniquesdescribed here can be implemented on a computer having a display device(e.g., a CRT (cathode ray tube), LCD (liquid crystal display) monitor,LED (light-emitting diode) or OLED (organic light-emitting diode)monitors) for displaying information to the user and a keyboard and apointing device (e.g., a mouse or a trackball) by which the user canprovide input to the computer. Other kinds of devices can be used toprovide for interaction with a user as well; for example, feedbackprovided to the user can be any form of sensory feedback (e.g., visualfeedback, auditory feedback, or tactile feedback); and input from theuser can be received in any form, including acoustic, speech, or tactileinput.

The systems and techniques described here can be implemented in acomputing system that includes a back end component (e.g., as a dataserver), or that includes a middleware component (e.g., an applicationserver), or that includes a front end component (e.g., a client computerhaving a graphical user interface or a Web browser through which a usercan interact with an implementation of the systems and techniquesdescribed here), or any combination of such back end, middleware, orfront end components. The components of the system can be interconnectedby any form or medium of digital data communication (e.g., acommunication network). Examples of communication networks include alocal area network (“LAN”), a wide area network (“WAN”), the Internet,or a satellite or cellular network data carrier.

The computing system can include clients and servers. A client andserver are generally remote from each other and typically interactthrough a communication network. The relationship of client and serverarises by virtue of computer programs running on the respectivecomputers and having a client-server relationship to each other.

A number of implementations have been described. Nevertheless, it willbe understood that various modifications may be made without departingfrom the spirit and scope of the invention. For example, much of thisdocument has been described with respect to messaging and mappingapplications, but other forms of graphical applications may also beaddressed, such as interactive program guides, web page navigation andzooming, and other such applications.

In addition, the logic flows depicted in the figures do not require theparticular order shown, or sequential order, to achieve desirableresults. In addition, other steps may be provided, or steps may beeliminated, from the described flows, and other components may be addedto, or removed from, the described systems. Accordingly, otherembodiments are within the scope of the following claims.

What is claimed is:
 1. A computer-implemented method for generating atoken set that associate permissions and privileges with a digitalidentity, the method comprising: receiving, from a requester and at acomputing device of a certification authority, a request for associatinga first index of privileges and permissions with a digital biometric,the first index specifically encoding the privileges and permissions ofa first subscriber in accessing transactional data of the requester, therequest including the digital biometric that identifies a person and hasbeen issued to the requester by a trusted entity through a vettingprocess; extracting, from the request, the digital biometric;determining that the extracted digital biometric is valid; verifyingthat the requester is the person identified by the digital biometricbased on a biometric of the requester matching the extracted digitalbiometric; in response to determining that the digital biometric isvalid and verifying that the requester is the person identified by thedigital biometric, associating the first index of privileges andpermissions of the first subscriber with the digital biometric; andproviding, to the requester, the digital biometric associated with thefirst index of privileges and permissions of the first subscriber, thedigital biometric enabling the first subscriber to access transactionaldata of the requester in accordance with the first index of privilegesand permissions.
 2. The method of claim 1, further comprising:receiving, from a requester and at the computing device of thecertification authority, a request for associating a second index ofprivileges and permissions with the digital biometric, the second indexspecifically encoding the privileges and permissions of a secondsubscriber, different from the first subscriber, in accessingtransactional data of the requester, the request including the digitalbiometric that identifies the person and has been issued to therequester by the trusted entity through the vetting process; extracting,from the request, the digital biometric; determining that the extracteddigital biometric is valid; verifying that the requester is the personidentified by the digital biometric based on a biometric of therequester matching the digital biometric; in response to determiningthat the digital biometric is valid and verifying that the requester isthe person identified by the digital biometric, associating the secondindex of privileges and permissions with the digital biometric of thesecond subscriber with the digital biometric; and providing to therequester, the digital biometric associated with the first index andsecond index of privileges and permissions, enabling the firstsubscriber and the second subscriber to access transactional data of therequester, respectively in accordance with the first index and thesecond index of privileges and permissions.
 3. The method of claim 1,wherein determining that the digital biometric is valid comprises:verifying that the digital biometric is issued by the trusted entitybased on a digital characteristic of the digital biometric uniquelyidentifying the trusted entity.
 4. The method of claim 3, whereindetermining that the digital biometric is valid further comprises:verifying that the person identified by the digital biometric is notlisted in a negative-indicator database.
 5. The method of claim 1,wherein determining that the digital biometric is valid comprises:verifying that the digital biometric has not expired or been revoked. 6.The method of claim 1, wherein determining that the digital biometric isvalid comprises: determining a score of trustworthiness of the digitalbiometric.
 7. The method of claim 1, wherein providing the digitalbiometric associated with the first index of privileges and permissionscomprises: transmitting data encoding the digital biometric associatedwith the first index of privileges and permissions to the requester. 8.The method of claim 7, wherein providing the digital biometricassociated with the first index of privileges and permissions furthercomprises: signing the digital biometric with a digital signature of thecertification authority.
 9. The method of claim 8, wherein signing thedigital biometric further comprises: digitally watermarking thecredential token with information uniquely identifying the certificationauthority.
 10. The method of claim 7, wherein providing the digitalbiometric associated with the first index of privileges and permissionsfurther comprises: encrypting the digital biometric with a digital keyof the certification authority.
 11. The method of claim 7, whereinproviding the digital biometric associated with the first index ofprivileges and permissions further comprises: generating additional dataattesting to the integrity of the data encoding the digital biometric.12. The method of claim 1, wherein receiving the request comprises:receiving a digital biometric issued by a government entity to therequester, the digital biometric being a primary identity certificatethat is issued after a vetting process conducted by the governmententity on the person identified by the digital biometric.
 13. Acomputer-implemented method for generating a token set that associatepermissions and privileges with an identity, the method comprising:receiving, from a requester and at a computing device of a certificationauthority, a request for associating a first index of privileges andpermissions with a foundation token, the first index specificallyencoding the privileges and permissions of a first subscriber inaccessing transactional data of the requester, the request including thedigital biometric that identifies a person and has been issued to therequester by a trusted entity through a vetting process; extracting,from the request, the foundation token; determining that the extractedfoundation token is valid; verifying that the requester is the personidentified by the foundation token based on a biometric of the requestermatching the extracted digital biometric; and in response to determiningthat the foundation token is valid and verifying that the requester isthe person identified by the foundation token, associating the firstindex of privileges and permissions of the first subscriber with thefoundation token; and providing, to the requester, the foundation tokenassociated with the first index of privileges and permissions of thefirst subscriber, the foundation token enabling the first subscriber toaccess transactional data of the requester in accordance with the firstindex of privileges and permissions.
 14. The method of claim 13, furthercomprising: receiving, from a requester and at the computing device ofthe certification authority, a request for associating a second index ofprivileges and permissions with the foundation token, the second indexspecifically encoding the privileges and permissions of a secondsubscriber, different from the first subscriber, in accessingtransactional data of the requester, the request including thefoundation token that identifies the person and has been issued to therequester by the trusted entity through the vetting process; extracting,from the request, the foundation token; determining that the extractedfoundation token is valid; verifying that the requester is the personidentified by the foundation token based on a biometric of the requestermatching the foundation token; in response to determining that thefoundation token is valid and verifying that the requester is the personidentified by the foundation token, associating the second index ofprivileges and permissions with the foundation token of the secondsubscriber with the foundation token; and providing to the requester,the foundation token associated with the first index and second index ofprivileges and permissions, enabling the first subscriber and the secondsubscriber to access transactional data of the requester, respectivelyin accordance with the first index and the second index of privilegesand permissions.
 15. The method of claim 13, wherein determining thatthe foundation token is valid comprises: verifying that the foundationtoken is issued by the trusted entity based on a digital characteristicof the foundation token uniquely identifying the trusted entity.
 16. Themethod of claim 15, wherein determining that the foundation token isvalid further comprises: verifying that the person identified by thefoundation token is not listed in a negative-indicator database.
 17. Themethod of claim 15, wherein verifying that the requester is the personidentified by the foundation token further comprises: confirming thatthe requester is the person identified by the foundation token byinquiring at a third-party certification authority, different from thetrusted entity, that the requester is the person identified by thefoundation token.
 18. The method of claim 13, wherein determining thatthe foundation token is valid comprises: verifying that the foundationtoken has not expired or been revoked.
 19. The method of claim 13,wherein determining that the foundation token is valid comprises:determining a score of trustworthiness of the foundation token.
 20. Themethod of claim 13, wherein providing the foundation token associatedwith the first index of privileges and permissions comprises:transmitting data encoding the foundation token associated with thefirst index of privileges and permissions to the requester.